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Predicting the Future 

All those software managers who ask for project 
completion dates are engaged in the difficult 
practice of "Predicting the Future." As each of us 
watches the marketplace with announcements 
and shipdates, we come to our own conclusions 
about the difficulty of predicting any kind of 
schedule. 

Those who go for longer-term predictions 
("futurists") have their own problems. My early 
grade school years were filled with interesting 
predictions and fears: gyrocopters for transporta¬ 
tion (easy now to see how this wasn't a hot idea), 
30 hour work weeks (easy extrapolation-who 
would have guessed that workers would prefer 
to work 10 more hours in exchange for more lux¬ 
uries), fear of people being replaced by comput¬ 
ers (well...), and, of course, all kinds of 
predictions about the space program. 

One recent event has heightened my understand¬ 
ing of the difficulty of future prediction. Over the 
last several years, we have heard about improved 
eyeglasses and better contact lenses. I don't recall 
anyone predicting that a cure for near-sighted¬ 
ness (myopia) was possible. 

You might have heard of the new operation called 
"radial keratotomy" (RK), in which incisions 
change the eye's support structure so that it 
reshapes itself into the correct form. RK was 
invented in Russia after a doctor noticed dra¬ 
matic eyesight improvement in his patient who 
recently suffered broken glass in his eye. 

My roommate, Jeff, is an avid outdoorsman and 
found his glasses cumbersome and, sometimes, 
unsafe. Last month his two eyes rated 20/400 and 
20/600. Jeff elected to take the risk of RK. Now, 
his eyes are rated at 20/15. Cool. The cost was 
reasonable, too. 

Knowing the next neat development is always a 
fine skill (consider its value at start-up compa¬ 
nies). It looks like a really difficult task. 

RK 

The closing date for submissions to the next issue 
of ;login: is June 28. 
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Mach Symposium Report 


Report on the Third USENIX Mach Symposium 
Santa Fe, New Mexico 
Aprii19-21,1993 

by Dave Mitchell 

<dwm@orca.com> 

Participants in the third USENIX Mach Sympo¬ 
sium enjoyed cool sunny weather at an elevation 
of roughly 7000 feet in Santa Fe, New Mexico dur¬ 
ing the third week of April. Over 250 researchers 
and system programmers who work with Mach 
attended the day of tutorials and two days of 
technical presentations, attendance similar to that 
of the previous gathering held in November, 1991 
in Monterey, California. 

The initial day of tutorials offered useful instruc¬ 
tion in various aspects of Mach 3.0, from general 
introductions to the microkernel and using its 
IPC services, to porting issues and the principles 
of constructing external user-mode memory 
managers. 

Tuesday, April 20 

The program chair, David L. Black (OSF) noted in 
opening that this was gratifying, given that not 
too many years ago the entire population of 
Mach-knowledgeable people could (and often 
did) fit into one room. 

Sape Mullender (U. of Twente, Netherlands) 
began the keynote address by discussing the 
requirements for an operating system (OS) to 
support research activity Support for fast proto¬ 
typing is necessary and in turn requires that the 
OS be configurable, have a short learning curve, 
and hence enable wild ideas to be tried quickly It 
should also impose minimal overhead and allow 
accurate measurements while still supporting 
realistic loads and testing in an environment of 
day-to-day usage (i.e., Emacs has to run). He then 
listed some of the reasons that microkernels are 
now fashionable: they're easier to port, more con¬ 
figurable, and have cleaner interfaces, which lead 
to improved maintainability, confidence in cor¬ 
rectness, and ease of modification. After a suit¬ 
ably dramatic pause, he pointed out that well- 
designed integrated kernels offer the same 
advantages along with better performance. The 
obviously correct goal is then to try to obtain both 
sets of advantages, perhaps by using compilation 
options to choose between threads using proce¬ 


dure calls or separate processes using remote pro¬ 
cedure calls (RPCs) to communicate. 

His own work is currently centered around dis¬ 
tributed multimedia applications, and he advo¬ 
cates having sufficient OS support to avoid 
having to embed any application knowledge into 
the OS. His students currently develop under 
UNIX, working on an OS named Wanda. Wanda 
supports a globally-shared wide (64 bit) address 
space, real-time scheduler, and fast access to stor¬ 
age devices. Wanda can support a multiple 
address space model where RPC and system calls 
are used for debugging, or can be relinked as a 
"monolithic blob" where communication is done 
using procedure calls. Noting that having a single 
address space does not imply having only a sin¬ 
gle protection domain, Sape said that the best 
microkernel is one that is properly designed for 
the problem at hand, with easily replaced mod¬ 
ules; he urged people to be pragmatic, not dog¬ 
matic, about OS choice. 

Sape outlined his current project, a multimedia 
platform consisting of compute nodes, storage 
nodes, cameras and workstations with displays, 
all connected through a modular ATM switch, 
joking that ATM stands for "Awfully Tiny Mes¬ 
sages." 

The first group of four papers discussed some of 
the structural issues of implementing OS person¬ 
alities; 

Tatsuo Nakajima (CMU) talked about the prob¬ 
lems of writing real-time servers which ensure 
predictable service response hmes. Real-time 
Mach provides a set of mechanisms and policies 
for implementing real-time servers. His group 
has been working on server models (and system 
support for them) providing real-time resource 
management, improved preemptability, and pri¬ 
ority inheritance. They have found that the neces¬ 
sary predictability and analyzability have a cost, 
and that a fair part of it comes from the mismatch 
of some existing facilities, such as the Mach inter¬ 
face generator (MIG), to real-time needs. 

Paul Roy (OSF) presented work done to extend 
UNIX file services into a multicomputer environ¬ 
ment. Several data structures from traditional 
UNIX implementations (such as open file struc¬ 
tures, vnodes, mount points) are represented by 
ports. A distributed token passing scheme is used 
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to provide atomicity, with callbacks from fileserv- 
ers used to revoke possession as necessary. Sev¬ 
eral attributes are cached locally for efficiency: 
file size, seek pointer, and the accessed and mod¬ 
ified bits (the actual dates are managed by the 
fileservers). Reading and writing are imple¬ 
mented using vm_map in conjunction with hcopy. 
Paul then outlined the disk block reservation 
mechanism used to support UNIX ENOSPC 
semantics. This led into a discussion of ways that 
Mach might better support UNIX servers; the 
problems all stemmed from the decomposition of 
services into the server/microkernel structure, 
with the looser coupling leading to loss of infor¬ 
mation across these boundaries. An example of 
this is the use of a page fault to bring in the con¬ 
tents of a mapped file: the fault handler has no 
hint about the intended size of the access, and 
must deal in single whole pages, making it harder 
for the server to keep the file size coherent, and 
slowing large accesses. 

Jay Lepreau (U. of Utah) outlined the work done 
by his group to mitigate the costs of modularity 
and protection afforded by the traditional micro¬ 
kernel design. Applications pay a substantial cost 
in performance due to the traversing of multiple 
layers of software, various protection domains, 
and the use of an overly general and powerful 
RPC mechanism. Jay's group has designed a 
mechanism to load trusted server code into the 
microkernel, allowing more efficient communica¬ 
tions between the user program, server and ker¬ 
nel. They have eliminated the use of RPC 
between the application and server if on the same 
node, using a trap instead. These enhancements 
have all been hidden behind the interface genera¬ 
tor, in the stubs generated by MIG; the same 
server binary can run in or out of the kernel, and 
old programs continue to run, though without 
the improved performance. Though further opti¬ 
mizations and RPC short-circuiting remain to be 
done, the preliminary speedup is promising. 

Simon Patience (OSF) presented work done in 
Grenoble, France to remove the emulator from 
the OSF's microkernel architecture. Originally, 
the emulator was used to provide compatibility 
for BSD binaries which made trap-based system 
calls that weren't understood by Mach. Other 
performance optimizations also crept into the 
emulator over time. Most problems with the 
emulator stemmed from it living in the address 
space of the process. This foreign entity wasn't 
understood by debuggers or their users, and the 
emulator couldn't be trusted by the server since 
malicious or errant code could overwrite it. This 
caused the server to grow ever more complicated, 
since it had to verify every request from the emu¬ 


lator, and much functionality was duplicated in 
both places. Removing the emulator while 
remaining at least performance neutral with the 
older version required several enhancements to 
Mach. A generalized and more efficient exception 
mechanism was added to avoid having to make 
multiple RPCs to the microkernel for each system 
call. This exception mechanism was then used to 
build more efficient system call redirection into 
Mach. Copyin/out functionality had to be 
changed to directly read/write the process's 
address space, rather than relying on information 
in the request RPC. VmjreadO and vm_write() 
were enhanced to deal with requests that were 
not page aligned and not an integral number of 
pages, and to avoid the use of out-of-line data in 
some cases. Simon showed the new design to be 
at least performance neutral, though a number of 
key optimizations have not yet been done. 

After lunch, the next block of three papers dis¬ 
cussed interprocess communication: 

Hilarie Orman (U. of Arizona) talked about 
implementing Mach interprocess communication 
(IPC) abstractions over networks, using the x-ker- 
nel. She described the protocol stack design, 
including the detection of node failure using the 
Easter Algorithm: when a node is reincarnated 
(i.e., rebooted) the other nodes infer that it must 
have died at some time in the past. She presented 
timing data showing the efficiency of the x-kernel 
design, and pointed out the flexibility inherent in 
the layering of their protocol. 

Kenneth Koontz (John Hopkins U.) told of his 
efforts to use Mach RPC in an application involv¬ 
ing data acquisition, requiring large numbers of 
small messages. Not surprisingly, he found the 
performance to be lacking. His solution was 
implemented purely as a layer of user-mode code 
wrapped around mach_msg(): Port Buffers. Many 
messages are packaged together into one large 
message, which is sent when the buffer is full, 
when a timeout expires, or by explicit user 
request. He improved remote message delivery 
rates by an order of magnitude, local rates by a 
factor of three, and pointed out that further 
improvements and tuning should better the 
results. 

Michael Ginsberg (CMU) found that Xll per¬ 
formed abysmally when it used sockets imple¬ 
mented by the server on top of Mach 3.0. He 
described the work necessary to present the tradi¬ 
tional UNIX interface to X clients, while switching 
the underlying implementation to Mach IPC or 
shared memory. He found that by using native 
Mach IPC he could get performance slightly bet¬ 
ter than that of a monolithic kernel, but that the 
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use of Mach shared memory primitives provided 
speedup in excess of 40%. 

The last group of three papers presented on Tues¬ 
day revolved around threads and timers: 

Stefan Savage (CMU) discussed improvements 
made to support increased precision in the mea¬ 
surement of time, synchronization, and schedul¬ 
ing. While working on real-time threads, they 
found the usual timing and synchronization 
primitives to be lacking; more precision was 
needed, and the relative nature of time deltas 
coupled with scheduling uncertainties gave them 
motivation to invent two new abstractions: clocks 
and timers. Timers are active objects which allow 
users to synchronize with time in a variety of 
ways. Clocks are devices which measure the pas¬ 
sage of time and support the use of timers to a 
particular degree of accuracy. Together, these new 
abstractions allow various highly-accurate hard¬ 
ware devices to be easily integrated into a Mach 
system and accessed in a consistent and useful 
way. 

Paul Barton-Davis (U. of Washington) presented 
the work performed to add scheduler activations 
to Mach 3.0. Traditional user-level threads pack¬ 
ages are implemented on top of kernel threads, 
and suffer from various problems ranging from 
poor performance to incorrect behavior due to 
the mismatch between the two. Blocking kernel 
operations such as I/O, page faults and processor 
preemption are difficult for the user-level code to 
deal with, since much of that information is hid¬ 
den inside the kernel. Scheduler activations are 
an alternative to kernel threads that support user- 
level management of parallelism by providing 
upcalls allowing the kernel to notify the user- 
level scheduler of system events that affect the 
job. Processors are allocated to jobs by the kernel, 
the user-level thread scheduler controls which 
threads run on a job's allocated processors, and 
the user-level scheduler notifies the kernel of 
changing demand for processors. In return, the 
kernel never time-slices scheduler activations, 
and gives the user-level scheduler a chance to 
deal with events that are normally invisible to it. 
All of this is hidden behind the C threads inter¬ 
faces. Paul presented compelling evidence for the 
increased run-time efficiency this provides to 
applications. 

Randall Dean (CMU) presented his work in using 
continuations to improve the performance of the 
C threads library. He found that aggressive sav¬ 
ing of thread state before entrance into the C 
threads package, coupled with flattening of the C 
threads locking hierarchy increased throughput 
and decreased context switch latency substan¬ 


tially. In response to questions from the audience, 
Randy said that his work was complementary to 
the previously presented work on scheduler acti¬ 
vations, not mutually exclusive. 

Wednesday, April 21 

The first group of papers presented in the morn¬ 
ing were from efforts at IBM to support multiple 
concurrent OS personalities on Mach: 

Guy Sotomayor, Jr. (IBM) presented work done at 
IBM in Boca Raton, Florida and Austin, Texas to 
make Mach device drivers more general, modu¬ 
lar, and to run them in user-level tasks. He stated 
that the current Mach device drivers, derived 
from the BSD device drivers used in Mach 2.5, 
have been widely regarded as one of the weakest 
features of the system. IBM has followed up on 
work done at CMU to run device drivers as user- 
level tasks, and also revamped the device-driver 
model to separate device access from device 
operation so that multiple device drivers can 
cooperate in managing a single piece of hard¬ 
ware. They plan to support multiple cooperating 
OS personalities on a single platform. The whole 
scheme is built on a message-based protocol for 
invoking device-driver services. 

Ravi Manikundalam (IBM) spoke about their 
implementation of Multiple Virtual Machines 
(MVM), on Mach 3.0. In order to be able to use the 
extremely large body of legacy software built for 
PC DOS systems, they have constructed emula¬ 
tion for Windows 3.0 and 3.1, and DOS, including 
its protected-mode interface. This work required 
some extension of the Mach microkernel includ¬ 
ing a revamped fast exception mechanism and a 
virtual memory interface to allow portions of an 
address space to be reserved (to avoid having 
Mach plunk out-of-line messages into an incon¬ 
venient area). This paper is one of several to point 
out the utility of improvements in Mach excep¬ 
tion handling and MIG RPC. Though further work 
remains to be done, both Windows 3.0 and 3.1 
work and versions of DOS from 3.3 - 5.0 boot and 
run. 

James Arendt (IBM) spoke about creating an 
OS/2 flavored server. This work also used the VM 
reservation interface; otherwise, the Mach VM 
model seemed a good match for C)S/2, which 
maps some facilities on demand, using guard 
pages to detect the need to grow a stack or attach 
to a shared memory region. The Mach scheduler, 
however, lacks the variety of capabilities of the 
OS/2 2.x product, requiring them to fold their 
mapping of scheduler features into a functional 
subset. 
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The last group of papers for the morning session 
concerned memory management: 

Inshik Song (Seoul National U.) talked about 
work done to reduce page-in delay time by 
prefetching pages based on a task's page fault 
history. When a page is requested from the vnode 
pager, the history buffer is consulted; if another 
page was requested following the previous time 
the page was faulted in, the pager prefetches that 
page in anticipation of its use. Page prefetching 
was shown to yield good results in most cases, 
but future work will investigate reducing the 
prefetch overhead, and evaluate moving the 
prefetch logic into the microkernel, for closer cou¬ 
pling with VM internals. 

Khien-Mien Chew (U. of Texas, Austin) spoke 
about a collaborative effort to get closer coupling 
between database management systems and the 
kernel's virtual memory support. Databases gen¬ 
erally would prefer to manage their pages 
directly, avoiding the overhead of having the ker¬ 
nel page beneath them, since the database has 
more accurate knowledge of its own require¬ 
ments. However, the kernel cannot page directly 
to/from the database file, since it knows nothing 
about the consistency and ordering constraints 
required by the database to be able to cope with 
system failures. The solution implemented was to 
allow the kernel to page directly to/from the 
database files, but to provide flush-locks for intra¬ 
page consistency, and give the kernel knowledge 
of page flush ordering constraints ("page-flush 
before rules") to control database consistency. 

Philippe Bernadat (OSF) presented work done to 
adapt Mach to run on machines lacking page- 
based virtual memory support, such as the seg¬ 
mented Cray vector supercomputers or trans¬ 
puter- based real-memory systems. Mach was 
designed with the assumption that the underly¬ 
ing hardware includes a page-based memory 
management unit, enabling the use of a large, 
sparse virtual address space. Philippe described 
the machinations gone through to eliminate the 
use of submaps and minimize or eliminate frag¬ 
mentation by coalescing address map entries, 
perhaps extended over what are logically holes in 
the address space. Copy-on-write cannot be used 
to lazily evaluate memory copying, because a real 
memory system cannot assume that write refer¬ 
ences can be detected and responded to. Perfor¬ 
mance numbers showed that lack of virtual 
memory is not always a handicap (every feature 
has its cost) and that where performance was 
worse, the extra copying required completely 
accounted for the slowdown. 


The first group of papers after lunch were about 
distributed systems. 

Miguel Castro (INESC) presented "MIKE - A Dis¬ 
tributed Object-Oriented Programming Platform 
on Top of the Mach Microkernel" which allows 
the use of C++ much the same way it would be 
used in a nondistributed system. The platform 
supports fine-grained objects which can be 
invoked in a location transparent way, and which 
are potentially persistent. MIKE supports the 
abstraction of one-level store; persistent objects 
are transparently loaded on demand when first 
invoked and saved to disk when the application 
terminates. The platform also offers distributed 
garbage collection of nonpersistent objects. 

Dejan Milojicic (U. of Kaiserslautern) presented 
the design and implementation of task migration 
on top of the Mach microkernel. This was done at 
user-level in the interest of portability and flexi¬ 
bility, though some modifications to the kernel 
were needed. The actual migration is accom¬ 
plished by: 

• Suspending the task and aborting the threads to 
get clean state 

•Interposing the task/thread kernel ports 

•Transferring the address space 

•Transferring threads by getting local and setting 
remote state 

•Transferring the capabilities 
•Transferring the other task/thread state 

• Interposing back the task/ thread kernel ports at 
the remote site 

•Resuining the (now remote) task 

This work also supported various memory copy¬ 
ing strategies, such as eager copying, flushing, 
and copy-on-reference. Further research will cen¬ 
ter on load distribution and distributed schedul¬ 
ing problems. 

Mark Swanson (U. of Utah) talked about the 
Schizophrenic Workstation System, which dis¬ 
tributes processing load among a network of 
autonomous workstations in a non-intrusive 
manner. Besides the technical problems of imple¬ 
menting migration and deciding when to balance 
load, they set out to build in a solution to the 
sociological problem: owners of workstations 
want response-time guarantees, and want the 
illusion that the machine is entirely theirs to use 
as needed, allowing them to plan their work 
around the predictability of computation. This 
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was accomplished by depressing CPU priority 
and constraining competition for physical mem¬ 
ory by Schizo processes, and by migrating a task 
to another host when the current host load 
becomes too high. 

The final paper was by Michael Kupfer (UCB) 
talking about his work to produce a Sprite server. 
The difficulties encountered involved dealing 
with exceptions in the server from failed copy- 
inOs, and problems with signal delivery. The end 
result was 22% smaller than an equivalent Sprite 
kernel, and contained almost no machine-depen¬ 
dent code. Though the result ran at 38% of the 
speed of native Sprite, Michael indicated that 
many of the reasons for the slowdown were 
understood and could be fixed. 

After all of the papers had been delivered, several 
people gave ten minute briefings on their work in 
progress: 

Dejan Milojicic plans to investigate using net¬ 
work paging and IPC traffic information to 
improve load distribution decisions. Initial 
efforts will be based on periodically disseminated 
statistics by all nodes involved. 

Brent Welch (Xerox PARC) spent his time-slice 
giving a shameless plug for Sprite, finally tossing 
the Sprite distribution CD he'd brought with him 
out into the audience. 

Jose Rogado (OSF) spoke about ongoing work on 
the Cluster Port File System, intended to be a 


replacement for the existing distributed multi¬ 
computer file system, optimized to minimize the 
number of messages passed. 

Mihael Bushnell (FSF) talked briefly about the 
Gnu Hurd server, confident that his user-level 
implementation of signals would pass VSE test¬ 
ing quickly. He declined to estimate a possible 
release date, since "software folks never know 
how fast they'll work." Many of us have yearned 
for that luxury 

Jay Lepreau spoke about his work in flexible sys¬ 
tem structuring, designed to get optimum system 
performance via intelligent and persistent load¬ 
ing of programmable executable objects. Nearly 
maximal buzzword usage, too! 

Santosh Rao (USC) sketched out his ideas on 
resource management for distributed virtual sys¬ 
tems, concentrating on scalable techniques, and 
coping with heterogeneity through the abstrac¬ 
tions of job managers and node managers. 

Franklin Reynolds (OSF) outlined recent work 
done to implement untyped IPC, an attempt to 
gain performance by simplifying the representa¬ 
tion of messages to avoid kernel involvement in 
having to read and parse each message in its 
entirety. Some common cases were improved by 
also perforirung an eager copy on transmission, 
page stealing if the deallocate bit is set, and by 
overwriting an existing buffer (avoiding zero-fill 
faults for new memory). 


k Changing of the Guard 


by Jeffrey S. Haemer 
USENIX Standards Liaison 

<jsh@canary.com> 

Many of you saw the call for applications for a 
new USENIX Standards Report editor. In fact, 
many of you applied. Well, after many weeks of 
black smoke, white smoke is finally rising from 
the chimney of the USENIX office in Berkeley. We 
have a new standards report editor: Nick Stough¬ 
ton (rhymes with "Stoughton"). For history buffs, 
he's the fourth in this job, making him 
***Shane_McCarron. 

Nick tells me that the earliest UNIX version he felt 
really comfortable with was 6th Edition UNIX, 
though he did spend time working on 5th Edition 
UNIX before V6 was available. He also lays claim 
to having been part of the first 4.1BSD port in the 


United Kingdom; this latter is surely related to 
his being English, which means that Carolyn Carr 
and Sean Eric Fagan, curators of ;login: and 
comp.std.unix, may have to begin running 
"spell -b." You can write to Nick at 
<nick®usen ix.org >. 

It is my official job, at this point, to offer Stephe 
Walli thanks from USENIX for a job truly and gen¬ 
uinely well done. I'm personally sorry enough 
that he's retiring that I tried at least once to get 
him drunk enough to agree to continue. 

I urge readers who've appreciated Stephe's work 
as much as I have and who wish to stay in touch, 
to continue writing to him at <stephe@usenix.org>. 

The Snitch Editor is dead, long live the Snitch 
Editor. 
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SAGE Views 


Good Policy Is Stronger Than Asbestos; 

What To Do When Your Users Court USENET 
Flames 

by Hal Pomeranz 
QMS, Inc. 

<pomeranz@imagen.com> 

If you have been responsible for a USENET feed 
for any period of hme, chances are that one of 
your users posted inflammatory material to one 
or more newsgroups. The Internet is a big place 
and chances are good that somebody will be 
offended by every post made. However, we will 
consider cases here like the recent anti-Japanese 
polemic that was posted to nearly every news- 
group or the recent posting to rec.pets.cats advo¬ 
cating feline torture. The general response by the 
USENET community to such postings has been to 
(a) mail bomb the individual and/or (b) complain 
loudly to the site administrator that the poster 
should have his or her privileges revoked. As a 
system administrator caught in the crossfire, 
what should you do? 

You could do nothing. At the very least this will 
mean much more careful monitoring of your mail 
spooling area so that all of that hate mail doesn't 
overflow your partition, but that will die off in a 
few weeks - maybe. On the other hand, the poster 
is a representative of your institution. It may 
appear that your organization is tacitly condon¬ 
ing the poster's actions if you refuse to act. In fact, 
your organization may have a harassment policy 
or nondiscrimination statement that may require 
that some action be taken against the poster. 

You could take the frontier justice approach: lock 
the user out of his or her shrink wrap account, 
cancel the article (if possible), and post an apol¬ 
ogy (or force the poster to do it to get the account 
back). This will quell the hate mail quickly. (It will 
take up to a week for the apology to propagate 
out, though.) The downside is that you have 
taken responsibility for determining that a certain 
person originated the posting (remember that it is 
relatively easy to forge news), passed sentence, 
and delivered punishment. Good for you if you 
as a system Administrator have that much power 
in your site (and do you have any job openings?). 

Your safest bet may be the "common carrier" tac¬ 
tic that the phone companies use. The phone 
company must ensure that the obscene phone 


callers get a dial tone and that their call is con¬ 
nected to your number when they dial it. It is not 
their responsibility to hunt the caller down and 
prosecute, much less punish them, when they 
harass you. Similarly, as a system administrator, 
it is your responsibility to ensure that email, 
news, and other data gets to where it is supposed 
to go, and not to legislate content. It is probably 
not even feasible for you to do so, but leave that 
aside. 

This does not mean that your job is over once 
your news feed is working properly. Somebody 
has to be ultimately responsible for news and 
email that originates from your site or you're 
back to the "do nothing" position. The answer, 
unfortunately, is something that technical people 
usually dread: management. Here I mean man¬ 
agement in a generic sense - at an educational 
institution this usually translates to a Dean of 
Computing or Head of Department for cases like 
this. Simply saying, "It's management's responsi¬ 
bility," and abrogating any technical input, how¬ 
ever, is another way of asking to get your news 
feed shut off or seriously curtailed. 

You need to educate your managers on the bene¬ 
fits of news as well as the problems, and work 
with them to prepare in advance a complete pol¬ 
icy for news at your site. Such a policy should 
probably include a statement of which news 
groups you will carry ("all," "all comp and sci 
groups," "no alt groups," etc.), whether or not 
your users will be allowed to post (and to which 
groups), an acceptable use statement, possibly 
the text of a disclaimer to appear in all news arti¬ 
cles originating from your site ("the opinions 
expressed herein..."), and a policy on what to do 
when somebody from your site posts that "Hitler 
was right" on soc.culture.jewish. Make sure that 
all your users sign a copy of the policy, so there 
will be no question of "I didn't know." 

As an example, here at QMS our news policy is 
simple. We carry every group, subject to disk 
space limitations. (I can't carry the binaries 
groups and have to expire news rather quickly 
because my spooling partition is cramped.) Any 
user may post to any newsgroup. Questions of 
acceptable use are decided by the user's manager. 
In the event of an inflammatory posting, all mail 
about the posting is forwarded to the manager in 
charge of the person who appears to have posted 
the message. (Remember those forgeries.) I also 
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reply with a form letter to each person who com¬ 
plains: 

We have received your message regarding 
message ID <insert message ID hero which 
was apparently posted by a user at our site on 
or about <insert date/time>. Your message 
has been forwarded to the appropriate man¬ 
ager for consideration. Any further corre¬ 
spondence should be directed to <manager's 
name/title/email>. 

In the event of an incident, the system adminis¬ 
trator tends to be called in as an '"expert witness." 
You will probably have to explain the possibility 
of a forged message (the seriousness of this threat 
is determined by the technical expertise of the 
users at your site and amount of "bad blood") 
and to produce logging or accounting data to 
prove or disprove that a certain user was respon¬ 
sible for the posting (your logs are complete and 
secure, aren't they?). The posting will probably 
offend you as much as everybody else, but don't 
let that cloud your technical judgement. 

Ridiculous postings appear on the USENET all 
the time. If one originates from your site, the 
head-in-the-sand approach reflects badly on your 
institution and the lack of response only inflames 
the already offended. Reacting too fast and with¬ 
out authorization can end up getting the system 
administrator in more trouble than the poster. A 
policy prepared in advance with the full author¬ 
ity of your management and the consent of your 
user community will enable you to deal with 
these situations in an expedient and relatively 
painless fashion. Ultimately, though, this is an 
issue for management to resolve, not the system 
administrator. 

More Laws of System Administration 

by Paul Evans 
SRI International 

<ple^erg.sri.com> 

Steve Simmons and Elizabeth Zwicky are fond of 
collecting laws of system administration. Well, I 
have a new one for them to add to their collection. 

If users are made to understand that the system 
administrator's job is to make computers run, 
and not to make them happy, they can, in fact, be 
made happy most of the time. 

If users are allowed to believe that the system 
administrator's job is to make them happy, they 
can, in fact, never be made happy. Furthermore, 
in their quest for happiness, they will cause 


enough resources to be diverted to trying to make 
them happy that the computers will no longer 
run. 

My first job as a system administrator was in a 
group with a very strong technical lead. I will call 
him Don, because that was his name. Don had 
red hair and a temper to match. He wore the kind 
of moustache made popular by Josef Stalin. He 
had a cobra tattooed on one arm. He had hanging 
in his office a print of Frank Frazetta's "Dark 
Rider" (a barbarian horseman holding a bloodied 
battle axe), to which our boss had added a car¬ 
toon-style caption saying, "the System Adminis¬ 
trator is in...." 

Don did not have what pop business literature 
would call a "total customer service attitude," 
and in that regard set the tone for our whole 
group. He expected users to defer to him, and 
they did. He had, and was seen to have, total sup¬ 
port from the management of the company for 
which we worked. On the one occasion that a 
user challenged his authority — he said that Don 
should look for a new line of work — the user 
was fired the same day. Because it was made 
absolutely clear to everyone that Don's job was to 
make the computers run and not to make the 
users happy, the computers ran, and the users 
were happy. 

After Don left the company (which sued his new 
employer in an unsuccessful attempt to get him 
back), our group was incorporated into a unified 
engineering services group, which included 
drafting and document control. Because the other 
engineering services were explicitly in the busi¬ 
ness of making their customers happy, users 
began to draw the thoroughly false and pejora¬ 
tive analogy that the end and highest good of sys¬ 
tem administration should likewise be user 
happiness. As more and more system administra¬ 
tion resources were poured into the voracious 
maw of user support in a futile attempt to make 
the users happy, the reliability of the computers 
eroded badly, which made the users unhappier 
still. After fighting this downward spiral for a 
year, both remaining full-time system adminis¬ 
trators resigned in the same week. 

User happiness is an important outcome of effec¬ 
tive system administration. Paradoxically, how¬ 
ever, it is only possible to provide a level of 
service that will keep users happy when they've 
been explicitly told that making them happy is 
not what system administrators are paid to do. 
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Itty Bitty Boxes All Made Out Of Ticky- 
tacky 

by Eliiabeth D. Zwicky 
SRI International 

<zwicky@erg.sri.com> 

The delivery guy brings me a package from Boda¬ 
cious Software, Inc. 

Knowing that the new version of their WhizBang 
product is out, I indulge in the following day¬ 
dream: I take my keys out of my pocket, pick out 
one that I don't care about, and use it to rip open 
the top of the box in one smooth motion. Opening 
the box, I take out a piece of corrugated card¬ 
board on top, and underneath it is the software 
distribution. It is not shrink wrapped. If it is a CD, 
it's in a jewel box; if it's a tape it's in a normal tape 
box. It is not a floppy. The front and spine of the 
box, and the front of the CD (or the front and 
spine of the tape) say, in big clear letters 
"WhizBang Version 2.3 for Sun 4." This is the 
entire identifier; there are no more coded release 
numbers to find. If there's a serial number, it's on 
the media. The most important release notes and 
installation information are on an insert in the 
case with the media. Underneath the media is an 
installation manual, not shrink wrapped, no 
assembly required. It says "WhizBang Version 2.3 
Sun 4 Installation" on the front and the spine. 
Underneath that is a user manual, labelled 
"WhizBang Version 2.3 Sun 4 User Manual" on 
the front and on the spine. It's not shrink 
wrapped. It is fully assembled and ready to use. 
The box is now trash; there are no serial numbers 
and no important information stuck to it any¬ 
where. 

What happens when I stop daydreaming and 
actually open the box? Well, not that — not even 
once. First off, when I rip the key across the top of 
the box, half the time it doesn't work. Oops, it's a 
Sun CD box, and the flaps don't meet in a straight 
line; better get out the knife and feel for where 
and how it jogs. Double-oops, there's nothing 
between the lop of the box and the CD, and I've 
just blunted my knife and scratched the top of the 
CD (but hey, it makes it much easier to get the 
shrink-wrap off.) Or maybe it hasn't got a join 
across the top at all, and I need to figure out 
which piece of tape is covering up the flap. Better 
yet, maybe it's Solaris 2.0, which looks like one of 
those, but there is no flap, and no matter what 
you do to the top of the box, short of disembow¬ 
elling it by going right through the cardboard, 
you can't open it from the top. We used those 
boxes as a spectator sport, giving each one to a 
new person and seeing how long it took them to 


give up on trying to open it from the top and 
decide to do it "wrong" and rip the bottom open. 
The winner took over five minutes and mere 
words cannot capture the expression on his face 
when he discovered that in fact the designer 
intended you to open the box from the bottom. 

Once I have passed the intelligence test and got¬ 
ten the box open, we proceed to the test of dexter¬ 
ity and patience. The people who design these 
things appear to be for the most part frustrated 
designers of matrioshkas, those nested Russian 
dolls. Inside the box, possibly nestled in styro¬ 
foam peanuts, there is usually a shrink wrapped 
box. Stripping off the plastic allows me to remove 
a lightweight glossy slipcase (generally strength¬ 
ened by an inner or outer corrugated cardboard 
sleeve). Inside that there is a heavy cardboard 
slipcase. Inside it are a bunch of shrink wrapped 
manuals. 

If I'm lucky, there's also a separately shrink- 
wrapped CD in a jewelbox. CD packaging is one 
of those areas where innovation is popular, 
though. If I'm not lucky, the CD is inside one of 
the shrink wrapped manuals. This appears to be 
a thoughtful move on the part of the vendor, until 
you realize that I loan manuals to users. I don't 
want to loan my media to users. Not only are 
there lots of them who never return them, some¬ 
times they take them home — a not unreasonable 
thing to do with a manual you want to read — 
where my media are exposed to the uncontrolled 
influences of children and pets. I do not want to 
call vendors to ask for replacement media 
because their CD was eaten by an iguana. Tyvek 
envelopes are popular, but impossible to store 
logically, particularly when innovatively 
attached to other things. Then there are innova¬ 
tive cardboard boxes that are almost the shape of 
a jewelbox; it's a real pity that they're about an 
eighth inch larger than the slots in our CD racks. 

Of course, if I'm really unlucky, the manuals are 
in the form of shrink wrapped binders in which 
are two separate shrink wrapped sets of pages — 
the actual text and the index tabs for it. I am 
expected to assemble these components. A really 
innovative software company — Hewlett-Pack¬ 
ard, for instance — may provide me with an 
assortment of manuals, in different sizes and 
bindings, only some of which need to be assem¬ 
bled. (In Hewlett-Packard's case, they accom¬ 
pany this with a packing list that includes item 
numbers not only for the binder, the binder con¬ 
tents, and the binder labels, but also for the box 
that the packing list is in, and the labor it required 
to pack the box.) Or, going for maximum mystifi¬ 
cation, they may give me unlabeled binders and 
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slipcases, and put the labels elsewhere. There are 
two major theories for label distribution; you pro¬ 
vide all the labels together, where they're easy to 
get at but hard to match to their destinations, or 
you put them with the documents. The preferred 
method for providing the labels with the docu¬ 
ments is to shrink wrap something (the docu¬ 
ment or the index tabs for the document), 
optionally shrink wrap the labels, and then 
shrink wrap the two together. Now, I don't need 
to unpack all the user manuals; that can be left 
until somebody wants to read them. On the other 
hand, with the unlabelled binders, I have to open 
binders until I figure out which one is the one I 
want. By this point, Tm getting a little hasty about 
stripping off shrink wrapping, and small items 
like labels are flying wildly around the room. 
(This could explain all those slipcases with post- 
it notes stuck to them because nobody can find 
the labels.) 

On the outer box, there is at least one packing slip 
(frequently two, one from the software company 
and one from the shipping company). Inside the 
box — maybe shrink wrapped to things, maybe 
floating around loose somewhere or other — are 
5 or 6 other pieces of paper and cards. Some of 
them are valuable coupons, generally for things I 
don't want, but occasionally for things that I am 
passionately interested in. There's a piece of 
paper that either has a license, or a way to get a 
license; there's a piece of paper that tells me how 
to get support. There's frequently yet another pack¬ 
ing slip. These little pieces of paper are now inex¬ 
tricably mixed up with the backing for the labels, 
the slips that were inside the shrink wrap to tell 
me which labels match which documentation 
which match which index tabs, and any pieces of 
paper I might happen to have had already. They 
will all have to be sorted out and either thrown 
away or filed. 

I have now spent, on average, about 15 minutes 
getting the software out of the box. My office is 
covered with removed shrink wrap, extra pieces 
of cardboard, and small paper shreds. I have sus¬ 
tained at least one paper cut, and I am beginning 
to feel a bit sullen about the entire enterprise. I 
decide that perhaps I'll install the software 
tomorrow, and put the software carefully on the 
shelf. I can't put the CD away until I find a jewel 
box to put it in so that it will fit on the rack. I have 
to reassemble the manuals into the slipcase(s) 
before I put them back. After another 5 minutes of 
hassle putting all the pieces on the shelf, in the 
tape or CD rack, or in the trash, as appropriate 
(after carefully reading all surfaces of the appar¬ 
ently discardable packaging, becomes sometimes 
the serial number is stuck to them), my phone 


rings. It's a user, who wants to know why he can't 
use WhizBang 2.3 yet, when they say they 
shipped it to us last week. When I finish explain¬ 
ing to him that shipping is not an instantaneous 
process, and that software does not install itself, 
the phone rings again. It's our shipping depart¬ 
ment; they have a pallet containing our other 39 
copies of WhizBang 2.3 (shrink wrapped, of 
course), and they want to know where to put it. 

I then go home, where my friends and loved ones 
start asking questions like "How can you dislike 
a piece of software when you haven't even tried 
to install it yet?" "Did you know that your pants 
are covered in little tiny cardboard shreds and 
there's plastic stuck to your hair?" "How can an 
otherwise intelligent person want to discuss card¬ 
board boxes?" 

The next day I go to get the package down from 
the shelf and install it. First I have to find it. We 
have an entire wall and a half of manuals. About 
a third of the manuals we own are spiral-bound 
with no name visible once they're on the shelf. 
Another 10% are paperbound but have blank 
white spines, or spines with only the company 
logo on them. Of the remaining manuals, under 
10% have the version number and the platform 
printed on the spine. At least 10% don't have it on 
the cover either; you can usually figure it out by 
pulling all the manuals that might be of interest 
and comparing the copyright dates. So pulling 
the manuals off the shelf may end up being 
another several minute challenge. If the installa¬ 
tion instructions are in the user manual. I'm in 
real trouble — the user who's dying for the 
upgrade will borrow the manual, and I'll have to 
track it back down to get the piece I need. 

The CD spine may be equally uninformative 
(especially if the CD came in an envelope and we 
had to transfer it to an unlabelled box). In some 
cases, the version information may be on the CD 
in coded form — oops, I meant to install the ver¬ 
sion with the rabbit on it, but instead I reinstalled 
the one with the kangaroo, when we had been 
running all the way up at pengmn. Of course, the 
version numbers on all three CDs are identical — 
it's just the picture that differs. Or, there may not 
be a CD. Quarter-inch and half-inch tapes are no 
more problematic than CDs. They don't stack as 
well, but they're harder to lose. (Those little boxes 
fit under things real well, not to mention that peo¬ 
ple in a hurry tend to take CDs out of carriers 
without putting them back in boxes, leaving for¬ 
lorn little stacks of naked CDs sitting in corners.) 
The vendor who shipped us its UNIX software on 
40 3.5 inch floppy disks, on the other hand, pre¬ 
sented whole new problems. There's nothing like 
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misplacing floppy #17 of 40 to really enliven your 
morning, and floppies fit under, behind, and 
between objects even better than boxed CDs. 

Now that I have succeeded in getting the soft¬ 
ware out of the box, onto the shelf, and back off 
the shelf, all I have to do is actually install the 
software. Oh, and open those other 39 boxes. I 


actually have a theory for that; I bring the whole 
stack to staff meetings, and we open them while 
we meet. This does add a certain odd note to the 
proceedings — it's not just the background noises 
provided by tearing cardboard, people struggling 
to remove shrink wrap, and boxes being thrown 
into corners, it's having everybody armed with 
knives. 


SAGE: Solaris Developers Conference Report 


Solaris Developers Conference 
Santa Clara Convention Center 
March 29-31,1993 

Elizabeth D. Zwicky 
SRI International 

<zwicky@erg.sri.com> 

I was sent to represent our division at the Solaris 
Developers' Conference, not because I have any 
pretensions of being a Solaris Developer, but 
because our division has several projects that are 
going to be using Solaris machines, and the sys¬ 
tem administration group is the only group 
involved with all the projects. Out of our group, I 
was chosen to go by the usually combination of 
bribery, threats, and being out of the room at the 
critical moment. 

As a nondeveloper, I wasn't expecting a lot; in 
fact, I brought a computer with me so that I could 
work while I listened (making me one of only two 
people sitting in a Sun conference using an Apple 
Macintosh PowerBook — surprisingly, nobody 
mentioned it to me, although I did hear people 
behind me snicker occasionally). Actually, I got a 
lot out of the gathering, after a very unpromising 
start. 

As a USENIX conference goer, I found the makeup 
of the attendees startling. The ratio of men to 
women was even higher than Tm accustomed to. 
(I'm used to there being a line for the men's room, 
but none for the women's. I'm not used to there 
being a line for the men's room, and nobody but 
me in the women's room.) The ratio of Sun 
employees to attendees at large was also star¬ 
tling; not only were all relevant developers 
imported for each talk, which was good, but 
every talk had a row of other Sun people standing 
in the back, which was a little weird. The first day, 
the ratio of press and managers to actual develop¬ 
ers was very high, as well — that's because the 
first day of the conference consisted primarily of 
an extremely glorified press conference. 


The press conference, which started late and ran 
long, contributed highly to the unpromising 
nature of the kick-off. When a conference is run¬ 
ning 30 minutes late before the first event, and 
over an hour late by the end of it, it makes me 
nervous. The live band, the scripted all-VP, 
almost all-male presentation, and the overly cute 
live demos all made me feel even more nervous. 
Only one of the demos failed, and I considered 
that one to be poetic justice; the moment the VP 
made a joke about his wife that was so sexist that 
he got hissed by the audience, the demo stopped 
working, and never did restart. (After that, he 
stuck to Bill Gates jokes, which provoked occa¬ 
sional yawns but no hisses.) 

From a system administrator's point of view, the 
kick-off was a mixture of good and bad news. 
There was a section of it devoted to system 
administration, but it was entitled "The First 
Hour: Installation and System Administration" 
and this concept that installation was pretty 
much all of system administration was pushed 
hard. There was a lot of hoopla about Sun's desire 
to simplify system administration so as to reduce 
the cost of ownership, and a demo of AdminTool 
which consisted primarily of putting up a text 
window and saying "Isn't that ugly" and then 
putting up AdminTool and saying "Isn't that 
pretty." This was followed by vague promises 
and improbable claims. For instance, the claim 
was made that you could now do all administra¬ 
tion remotely, and that Solaris would cut down 
the number of needed UNIX system administra¬ 
tors by a factor of 5, from 1 per 100 machines to 1 
per 500 machines. Estimating this ratio for our 
site is a little tricky, since we have part-time sys¬ 
tem administrators, and we don't separate UNIX 
system administration from PC and Mac admin¬ 
istration. But my best guess is that we currently 
run 200 UNIX machines with 5 full-time equiva¬ 
lents, throwing some doubt on their initial 
assumptions. 


12 ;login: May/June 1993 


The kick-off was followed by more vice-presi¬ 
dents with marginally less glitz (they lost the 
band and most of the stage set, but kept the giant 
wall-o-monitors). I only saw Adobe's version, 
which relied heavily on yet another video clip, 
but it was actually relatively funny. It did appear 
to assume that the entire world consisted of PC 
networks which were either not administered at 
all, or were administered by incompetents; I con¬ 
sidered it an advertisement for real administra¬ 
tion as much as for Adobe's software. A good PC 
administrator could have solved most of the 
problems shown without resorting to Adobe's 
software (an interchange format and associated 
programs); a network administered as badly as 
the one shown would be unlikely to be able to 
make use of Adobe's software. But it was a funny 
video. 

After the first day, the conference settled down to 
business. Most of the press and managers went 
elsewhere, and the presentations were given by 
project managers and senior developers who for 
the most part actually knew what they were talk¬ 
ing about, and who had a lot of help to fill in 
when they didn't. Unfortunately for me, some¬ 
body had carefully gotten them all to do over¬ 
heads in exactly the same format and display 
them using SparcStations and Island Presents. If 
they'd let everybody pick their own format, at 
least some of them would have picked a truly 
high-contrast color set and a font big enough to 
read. Instead, everybody used a navy blue back¬ 
ground, yellow and white lettering, and nothing 
but the title font was large enough for me to see. 
Aside from that, the technology was surprisingly 
reliable; I only saw one presenter crash the dis¬ 
play program, and one who put up a slide only to 
discover in horror that only half the text he'd 
tried to put on it appeared on the screen. 

The talk on AdminTool is adequately summed up 
by the answers to half of the question-and- 
answer section afterwards: "No, it doesn't do 
that." "No, we have no plans to release that." 
"That does sound useful; maybe in a future 
release." "Well, we're planning to create another 
version of AdminTool that will use ToolTalk, and 
we have to redo all those interfaces then, so we're 
not documenting them now. No, we have no 
schedule for doing that." "No, we have no plans 
to do that." "No, there are no hooks for running 
custom scripts when you add users, but you can 
edit the default dot files. No, I don't think you can 
add more files for it to install in new accounts." 
"Well, you can do that from the command line, 
but it's a little baroque; it's really much easier to 
write a C program." 


Sun is clearly still scrambling with the change to 
Motif; the biggest laugh anybody got all week 
was the poor presenter on OpenWindows 4 (I'm 
sorry, I mean "Sun's next window system prod¬ 
uct, currently internally code-named OpenWin¬ 
dows 4"), who ended with a summary in which 
he reiterated Sun's commitment to OpenLook. 

He meant Motif; his slide said Motif; half the back 
row practically shouted "MOTIF" the moment 
"OpenLook" slipped from his lips; but he was 
undone by years of practice defending Open- 
Look. 

My favorite speaker was Bruce Tognazzini. Part 
of this was the fact that he was the only speaker 
with no illegible overheads, which is the sort of 
nicety one expects from a human factors expert. 
Also, I was cheering for him to begin with; after 
all, he has caused Sun to produce instructions for 
how to write an "Open" dialog box that actually 
state what order things should be displayed in. I 
think it ought to specify the same order Is uses, 
which it doesn't, but I can live with any order at 
all as long as every application I have to deal with 
uses the same one. We have Wingz, IslandDraw, 
and Frame, and they use 3 different sort orders. 
I'm all for adventure, but not when I'm trying to 
open a file. In any case, he's an enjoyable speaker 
in the UNIX tradition; colorful, opinionated and 
imbued with a True Religion. 

Overall, I would go back again, but I think on day 
one I'd register and then quietly go do something 
else until the furor died down. On the truly frivo¬ 
lous side, the snacks were good if sometimes 
peculiar (frozen candy bars?), the toy pickings 
were slim but high quality (there was a nice float¬ 
ing pen), and the location (the Santa Clara con¬ 
vention center) was excellent. (OK, I'm biased, 
since I live 10 miles away, but the number of out- 
of-towners who spent their breaks out soaking in 
the sunshine seems to indicate that it isn't just 
me.) 

Open Meeting with SAGE Board of 
Directors at Cincinnati 

Meet the SAGE Board of Directors at the Summer 
USENIX Conference in Cincinnati, OH. Help 
shape the future of SAGE. Bring your questions 
and ideas to this open meeting on June 23, from 
6-8 pm. Check the BOF Board for location. 
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SAGE-AU Conference 


SAGE-AU Inaugural Conference and 
Annual General Meeting 
University of Melbourne, Australia 
Juiy7-9,1993 

Preliminary Announcement 

The System Administrators' Guild of Australia 
(SAGE-AU) will be hosting a conference in con¬ 
junction with its inaugural annual general meet¬ 
ing. The theme of the conference will be 
"Administering Networked Computers." 

With the coming of age of computer networks, 
more and more organizations have internal net¬ 
works of machines sharing information. Admin¬ 
istration of these machines involves solving far 
more complex problems than for standalone 
computers. System administrators are under 
increasing pressure to allow more and more inter¬ 
connection of machines without any loss of reli¬ 
ability or security. 

Conference Details 

SAGE-AU'93 will be a 3 day conference running 
from July 7-9,1993. The first day will be dedi¬ 
cated to tutorials on tools and techniques to aid 
system administration. 

The inaugural AGM will be held at the end of the 
second day. 

All other times will be allocated to presentations. 
A conference dinner will be held on the second 
night. 

The conference will feature a small trade show 
focusing on system administration tools. 

Tutorials 

Tutorial sessions will be either half-day or full- 
day duration. People wishing to present tutorials 
should submit an abstract and a preference for a 
half-day or full-day slot to the address below. 
Tutorials should be run in a lecture format. 

Attendance at tutorials will cost $100 for a half 
day and $200 for a full day. 


Registration and Fees 

Registration forms are available from the address 
below. The registration fee for SAGE members is 
$100. Nonmembers may register for $150. 

The registration fee does does not include the con¬ 
ference dinner. Registrants must indicate 
whether they wish to attend the conference din¬ 
ner on the registration form and pay an addition 
cost. In keeping with the low-cost, informal 
nature of the conference, the conference dinner 
may be held in a local restaurant, depending on 
numbers. 

The registration fee does not include attendance 
at tutorials. 

SAGE foundation membership is currently being 
offered for $30 ($20 annual subscription plus a 
$10 joining fee). 

Annual membership fees have yet to be set by the 
committee. 

Addresses 

Send all enquiries to regarding the conference to: 

Peter Gray 
Professional Officer 
Dept, of Computer Science 
University of Wollongong 
N.S.W. 2500 Australia 
Phone: +61 42 213770 
Fax: +61 42 213262 
Email: <pdg@cs.uozv.EDU.AU> 

Requests for general information about SAGE- 
AU and membership applications should be 
addressed to: 

Frank Crawford 

Australian Supercomputer Technology 

Woods Centre 

PMBl 

Menai 

N.S.W. 2234 Australia 

or emailed to <sage-info@meLdit.csiro.au>. 
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What’s Out There? 


Volume 1, Numbers 

by Jeff Kellem 
Beyond Dreams 

<composer@beyond.dreams,org> 

Overview 

As usual, projects have been plentiful and life has 
been hectic. I hope your winter has been enjoy¬ 
able. A lot has happened since the last issue of 
"What's Out There?" We now have a new Presi¬ 
dent of the United States, Bill Clinton, who seems 
to be somewhat willing to entertain technological 
efforts. It's unknown whether all those efforts 
will be good, but it's definitely a start in the right 
direction. 

In this issue, you'll learn how to find out what's 
happening within the U.S. Government (includ¬ 
ing the U.S. Budget!), at least as far as the PR peo¬ 
ple will allow (the good part); where to find 
discussions of the Clinton administration's recent 
support of a NSA - developed encryption chip 
(the bad part); information on Factsheet Five - 
Electric, a 'zine of 'zine reviews; and a change (yet 
again) in the NIC's location. 

U.S. Government Information 

It is now possible to obtain White House press 
releases electronically. Also included in these 
archives are speeches made by the President and 
other administration officials. This is definitely a 
step in the right direction from the new adminis¬ 
tration, You can obtain press releases via a variety 
of methods - USENET newsgroups, WAIS, gopher, 
and electronic mail. 

The press releases from the White House Com¬ 
munications Office are available on the following 
USENET newsgroups: 

alt.politics.Clinton 

alt.politics.org.misc 

alt.politics.reform 

alt.politics.usa.misc 

alt.news-media 

alt.activism 

talk.politics.misc 

The press releases are also available via both 
WAIS and gopher from 

sunsite.unc.edu 


If you don't have a WAIS or gopher client, you 
can access the information by telneting to sunsite- 
unc.edu - login as the following users: 

•For WAIS, login as "swais" (without 
the quotes, of course) 

•For gopher, login as "gopher" 

For more information on WAIS, see "What's Out 
There?" Vol 1, Number 1 in the May/June 1992 
issue of this newsletter. Gopher will be discussed 
in a future issue. 

You will be accessing the general WAIS and 
gopher servers, respectively at sunsite.unc.edu. 
You can login as the user "politics" to search (via 
WAIS) various U.S. politically related informa¬ 
tion. You can also view and search the 1994 U.S. 
Budget via both WAIS and gopher at sunsite.- 
unc.edu. 

If you choose to access the top-level gopher 
server at sunsite.unc.edu, look under the "Sunsite 
Archives" section for the press releases, U.S. Bud¬ 
get, and other related information. 

The press releases are also on CompuServe, 
America OnLine, the WELL, MCI, Fidonet, 
Peacenet, and Econet. 

The above are the preferred methods for access¬ 
ing the White House press releases. If need be, 
you can also obtain the press releases via email. 
The current email server is a simple automagic 
response mail server; it is not designed to handle 
letters, comments, or requests for specific infor¬ 
mation. To access the mail server, send email to: 

<clinton-info@campaign92.rg> 

with a Subject line of: 

HELP 

To sign up to automagically receive press 
releases, use a Subject line that starts with: 

RECEIVE 

followed by one of the following categories: 

ECONOMIC POLICY 

FOREIGN POLICY 

SOCIAL POLICY 

SPEECHES 

NEWS 

ALL 

Other commands that you can include on the 
Subject line are: 
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STATUS: 

list the groups you're signed up to receive 
REMOVE category: 

stop receiving whatever category you list 
WAIS: 

to obtain a WAIS query form to search the press 
releases 

Read the HELP message you receive to learn 
more about this mail server. You can also obtain 
the press releases via anonymous/tp from the fol¬ 
lowing sites, at least: 

sunsite.unc.edu /pub/academic/ 

political-science/white-house-papers 

ftp.cco.caltech.edu /pub/bjinccall 

cpsr.org /cpsr/clinton 

The White House Electronic Publications and 
Public Access Email Frequently Asked Questions 
(FAQ) list should be available at each of the 
archive sites for the White House press releases. 

The FedWorld BBS, operated by the National 
Technical Information Service, also makes the 
press releases available. You can reach The Fed- 
World BBS at +1 703/321-8020, with communica¬ 
tion settings of 8 data bits, no parity, and 1 stop 
bit. 

Email to the White House 

Another cool thing that is slowly starting to hap¬ 
pen is sending email to the White House. This 
system is still being set up and will take some 
time to fully develop. There's a lot of thought and 
work that needs to be done to do this properly. 
But, it is a start. Right now, it is not possible to 
receive electronic responses to your email letters. 
So, if you do send email to the White House, 
include your U.S. Postal address for replies. In the 
future, there will hopefully be a way to get elec¬ 
tronic responses, also. Use one of the following 
addresses to send email to the White House: 

<clinton-hq@campaign92.org> 

<75300.3115@compuserve.com> 

<clintonpz@aol.com> 

You can also send email to the White House 
directly from CompuServe, America OnLine, 
MCI, and Fidonet. 

All of this definitely seems to be a step in the right 
direction towards electronic access to the U.S. 
Government. Sure, it doesn't cover all the differ¬ 
ent areas where we might want access, such as 
FOIA and other publicly-available governmental 
records, but it is a good thing to start. Check it 
out! 


White House and NSA (Encryption) Clipper Chip 
Announcement 

On April 16,1993, the White House announced 
the development of an encryption chip for voice 
communications developed in conjunction with 
the National Security Agency (NSA) called the 
Clipper Chip, along with an initiative regarding 
telecommunications and privacy which could lit¬ 
erally affect almost every citizen in the United 
States. On the same day, AT&T announced a 
"secure" phone which incorporated this chip. 
Some important things to point out: 

•The encryption algorithm is remaining classi¬ 
fied. In the cryptography community, an 
encryption algorithm is only considered secure 
after it has been examined extensively and 
independently by a wide array of experts 
around the world. With an algorithm which is 
kept secret, there is no guarantee that it is 
secure and that the encryption method has no 
"back door" (allowing easy decryption for 
those, such as the NSA, that know the "back 
door") 

•Although the government has announced plans 
to use the chip in their own phones, they do not 
plan to use it for classified information, only for 
unclassified information. 

•This chip has been in the making for 4 years. It 
would seem that the Clinton administration has 
already made plans to use the chip, without 
public comment or discussion on a matter 
which is so important to the privacy of that 
same public. 

•It would seem that the Government might be 
granting a monopoly to Mykotronx, Inc. and 
VLSI Technology. It's unclear whether each 
company makes the entire chip or just parts 
thereof. 

•The key, which allows the information 
encrypted with this chip to be decrypted, is 
embedded in the chip. This means that once the 
key is known, the chip needs to be replaced to 
maintain private communications. This would 
usually mean replacing the entire device (e.g, 
telephone), anytime that the key was divulged, 
whether legally or not. The key is also transmit¬ 
ted along with your encrypted data, so that 
law enforcement can obtain it, which would 
allow them to decrypt your data without your 
knowledge.] 

•The 80-bit key is split into two (2) 80-bit pieces 
and kept in databases at two different escrow 
agencies. It's not clear how the key databases 
will be kept secure. It is also unknown if the 
classified encryption algorithm is any less 
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secure to brute-force attacks, once half the key is 
known. 

• A successor chip has already been announced, 
called the Capstone chip. The Capstone chip is 
supposed to be a ''superset'' of the Clipper chip 
and will include the "digital signature stan¬ 
dard" (DSS), which many in the cryptography 
community seem to consider insecure, as I 
recall. The NSA also developed DSS, which 
wasn't disclosed until CPSR filed a FOIA 
request with NIST (the National Institute of 
Standards & Technology). 

This announcement, in one way, is a step in the 
right direction - privacy and encryption technol¬ 
ogy are important to the general public and for 
international economic competitiveness. An 
inquiry on whether export restrictions on encryp¬ 
tion technology is good or bad is also a good 
thing. Currently, companies that want to include 
encryption as part of their products need to make 
two versions - one for domestic distribution and 
one for international distribution. 

On the other hand, there are too many things 
about the announcement which are bothersome 
and need to be discussed publicly. 

Both the Electronic Frontier Foundation (EFF) 
and the Computer Professionals for Social 
Responsibility (CPSR) have made public state¬ 
ments against the announcement. The CPSR has 
filed Freedom of Information Act (FOIA) requests 
regarding the plan. 

Online discussions of the announcement have 
been occurring all over the Net in various 
USENET newsgroups and mailing lists. Here's a 
sample of where you might find discussions of 
the Clipper Chip; 

USENET newsgroups: 

alt.privacy.clipper 

sci.crypt 

alt.security 

alt.privacy 

comp.org.eff.talk 

comp.security.misc 

comp.society.cu-digest 

comp.risks 

Mailing lists: 

<cypherpunks-requesi@toad.com> 

Also, check the archives for the various groups 
listed above, as things may have changed by the 
time this newsletter comes to print in June 1993. 


The official White House press release of the Clip¬ 
per Chip can be found via anonymous ftp from: 

csrc.ncsLnist.gov in /pub/nistnews 

or via the NIST Computer Security BBS at -il 
301 / 948-5717. It should also be available with the 
rest of the White House press release archives 
mentioned above. 

The EFF comments were first published in the 
EFFector Online Issue 5.06, which is available via 
anonymous/fp from: 

ftp.eff.org in /pub/EFF/newsletters 

Information from CPSR is available online via 
anonymous ftp from: 

ftp.cpsr.org in /cpsr 

The cypherpunks mailing list also maintains an 
archive. Information on the Clipper Chip can be 
found via anonymous/fp from: 

soda.berkeley.edu in /pub/cypherpunks/clipper 

Please read the announcement of the Clipper 
Chip encryption technology, think about it, and 
discuss the implications of this with your friends, 
congresspeople, and anyone else. 

Factsheet Five - Electric 

Factsheet Five is a hardcopy magazine which 
reviews 'zines. A 'zine is typically a small press 
publication, many times put out by individuals. 
The quality of 'zines, as with most things, varies 
greatly. And, that's where Factsheet Five comes in. 
Within Factsheet Five, you'll find reviews of 'zines 
on every subject imaginable. Issue #46 had 1,460 
reviews. They're hoping to break 2,000 for issue 
#47. Factsheet Five is highly recommended; you're 
liable to find at least something of interest in each 
issue. And, in the worst case, you can find out 
about the wide variety of stuff that people write 
about. 

So, why am I telling you about a paper publica- 
Hon? For one, it's a worthwhile publication to 
pick up. And, second of all, there's now Factsheet 
Five - Electric (F5-E), an online version of the 
reviews in Factsheet Five. You can access F5-E via: 

•The WELL, a public access computer system; for 
more information, call +1 415/332-4335. You 
can also connect to them from the Internet via 
well.sf.ca.us. 

•Anonymous ftp 
- {xomftp.msen.com in 

/pub/newsletters/Zine-Reviews/F5-E 
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- from src.doc.ic.acMk in 

/literary/newsletters/factsheet-five 

• WAIS (from wais,msen.com) 

•Gopher (from gopher.msen.com) 

For more information on Factsheet Five - Electric, 
send email to <jerod23@well.sf.ca.us>. For more 
information on Factsheet Five, itself: 

R. Seth Friedman 
Factsheet Five 
RO. Box 170099 
San Francisco, CA 94117-0099 

Miscellaneous Notes 

The Network Information Center (NIC) has 
changed once again. The site nic.ddn.mil will now 
only be handling MILnet information. The new 
NIC is called InterNIC at rs.internic.net and con¬ 
tains all other directory information. This change 
occurred on April 1st, 1993 (no, it was not a joke). 


Miscellany 


Call for Summarizers 

by Rob Kolstad 

;login: Editor 
<kolstad@bsdi.com> 

I'm very excited about an idea of publishing micro¬ 
summaries and micro-reviews of various journals, 
magazines, technical rags, and other widely distrib¬ 
uted technical media for ;login:. I think it would be 
of tremendous benefit to our members, and would 
allow them to keep up with a headline-oriented 
summary of recent technical news. 

If you're a subscriber to a technical journal (e.g., 
JACM, etc.) or a magazine or tabloid (CACM, Open 
Systems Today, Byte, EE Times, VAR Business, etc.) 
and would volunteer to summarize their exciting 
points, please contact me at <kolstad@bsdi.com>. I'll 
be happy to share a much-expanded documenta¬ 
tion of this idea with you. I anticipate that writing 
the summaries would take only a small amount of 
time to prepare per issue of any periodical you 
already read. Of course, appropriate recognition 
and fame would be accorded to volunteers. 

Correction 

Peter H. Salus reports: In the January/February 
1993 issue of this newsletter I inadvertently omitted 
crediting Tony Mason as one of the authors of the 
lex & yacc book in my column, "The Bookworm." 


So, start using rs.internic.net to search for sites 
and people registered in the directory. On a 
UNIX- like system which has the whois program, 
you can tell whois to search the new NIC via: 

whois -h rs.internic.net NAME 

where NAME is what you're searching for. 

What’s Next? 

In future issues, I will discuss such topics as 
travel-related archives, astronomy, gopher, and 
whatever else comes to mind. 

Till next time. I'll see you on the Net. 

Jeff Kellem is, among other things, a musician, 
a programmer/developer, an Internet explorer and 
consultant, a system administrator, and occasional 
writer. He is the founder of Beyond Dreams, an orga¬ 
nization which promotes information exchange and 
communication. He can be reached via email: 
<composer@beyond.dreams.org>. 


Annual Board Meeting 

The Annual Meeting of the Association will be held 
during the Open Meeting of the Board of Directors 
which is scheduled for June 22,1993 from 7- 8:00 
pm at the Hyatt Regency Hotel in Cincinnati, Ohio 
(site of the USENIX Summer '93 Conference). 

Errata A La Binderia 

As some of you may have already noticed, the bind¬ 
ery made an error in some copies of the March/ 
April issue of ;login:. The missing pages are 23-30 
and 47-54. If you haven't looked at your copy yet, 
please do. Let us know if you want to receive a new 
and complete copy of the issue. Please send your 
requests to <office@usenix.org>. 

Curly Quotes 

Some readers have expressed their annoyance with 
the quotation marks that are used in the typesetting 
of this newsletter. The double quotation marks cur¬ 
rently used here are Palatino's "curly quotes." The 
Palatino family of type does not make standard 
curly quotes. Theirs are angled and only appear 
"curly" when enlarged to a high degree. Thus, they 
appear to be incorrect to some eyes. This may cause 
the typographically-sensitive among us to rethink 
the fonts used in this newsletter. Well see... Carolyn 
Carr, Font Maven 
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AMD - The Berkeley Automounter, Part I 


by John N. Stewart 

<jns@na$.nasa.gov> 

At the 1993 World Conference on System Admin¬ 
istration, Networking, and Security (SANS II), I 
spoke briefly during the tips and techniques dis¬ 
cussion about the "universal" automounter, 
AMD. This article, along with two future ones, 
will present the features and techniques used 
here at the Numerical Aerodynamic Simulation 
(NAS) Facility, compare the features to Sun's 
automounter, and most importantly, offer loca¬ 
tions where more information can be obtained. 

One major design principle followed at the NAS 
is to port a common set of source files to the archi¬ 
tectures that the resulting binaries will use. Since 
we had no wish, or legal right, to port Sun's auto- 
mounter to SGI IRIX, Convex ConvexOS, or Cray 
Unicos we had one alternative: a publicly avail¬ 
able automounter. Our current environment 
includes AMD on Sun Sparc (SunOS 4.1.1 or 
later) and SGI (IRIX 4.0.5 or later), and the future 
holds Cray and Convex. 

For the 400+ workstation at the NAS, the work¬ 
station team maintains six Sun 4/490 fileservers 
that serve both the Sun and SGI architectures. 
Going back to the "common source" principle, 
the fileservers and all workstations have one map 
file which states which machines they mount and 
which machines are "backups" should their pri¬ 
mary go down, A primary could go down in 
either of the following ways: the server itself is 
off-line (for whatever reason) or the network link 
to the primary server has broken. In both cases, 
after a certain (configurable) delay time, a 
machine will notice that it cannot obtain its pri¬ 
mary server, and — through heuristic logic built 
into the mapfile — decide which machine to con¬ 
tact next. 

The map files contain logic designed around 
three parameters: the client's architecture (SGI or 
Sun), the architecture's subnet, and a "group." 
The subnet might be any one of the many subnets 
in our various buildings; the group is config¬ 
urable. When a primary server is unavailable, 
AMD attempts to mount a server on the subnet 
that exports that client's architecture. 

The "group" is a controlling group; it is one of a 
set that determines which lines in the mapfiles 
AMD looks at when mounting a remote partition. 


Here at the NAS, workstations in the AMD 
"admin" group mount fileservers read-write, 
while the AMD "workstation" group mounts 
fileservers read-only. Both group entries and their 
respective options are in the same mapfile; the 
machine "group" determines which line in the 
mapfile to consult. 

A key feature in AMD's maps is the management 
of a machine using itself as a server. Three of our 
fileservers export the TeX and clients partition for 
the workstations and other fileservers. If a user 
on the fileserver wants to run TeX, the fileserver 
may have it locally or the fileserver may have to 
mount it from a remote machine. In the local case, 
AMD knows that it does not need to mount; 
rather, it creates a symbolic link from the 
"mount" area to the locally installed TeX pack¬ 
age. In the latter, AMD mounts another fileserver 
in the "mount" area. This reduces unnecessary 
NFS activity and is easy to administer. 

Since our installation is large and presents great 
difficulty for management teams to notice 
whether or not a client's AMD was/is having dif¬ 
ficulties, AMD uses syslog through a local chan¬ 
nel. This enables centralized administration, 
logging, and record keeping for AMD's perfor¬ 
mance in our environment. AMD also has the 
capability to log through a logfile (avoiding sys¬ 
log) which, in some cases, will prove more appro¬ 
priate. 

The last key feature in AMD is its capability to 
mount different machines in different trees, yet 
still maintain a "common" point of access. Case 
in point: when a fileserver goes down, the old 
NFS partition is unmounted and the new one is 
mounted. The mount locations for the two (old 
and new) are different, which avoids problems 
with stale filehandles, problems during the 
unmount, and other anomalies. However, though 
both machines mount the filesystems in different 
places, a symlink will automagically change 
allowing the transparency we needed. 

My next article will discuss the important fea¬ 
tures lacking in Sun's automounter and how 
AMD answered our needs. Watch the next issue of 
this newsletter. 

You may obtain AMD at the usc.edu ftp repository 
in /pub/amd. You may join AMD's discussion list 
at <amd-workers-request@acl.lanl.gov>. 
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The TCP/IP Bakeoff 


by Pace Willisson 

<pace@bsdi.com> 

The 1993 TCP/IP Bakeoff was held the week of 
February 8th at the offices of FTP Software in 
North Andover, Massachusetts. The Bakeoff 
brought TCP/IP developers from many compa¬ 
nies together to hash out real world compatibility 
problems with the low level parts of TCP/IP 
implementations and with the basic applications 
such as telnet, ftp, mail, and printing. While there 
have been many testing events for the higher 
level standards such as SNMP, NFS and X, it has 
been 12 years since anything similar has been 
held for TCP/IP itself. 

The organizers of the event were very successful 
in creating an environment of cooperation among 
competitors. The participants agreed informally 
not to disclose details of the testing results in 
ways that would help or hurt individual compa¬ 
nies. Therefore, everyone in the room felt free to 
help one another. Every vendor left the event 
with ideas for improving its product, and those 
who brought source code were able to create and 
test fixes on the spot. 

The bugs uncovered ranged from system crashes 
caused by pathological packets to garbled screens 
caused by invalid assumptions of terminal capa¬ 
bilities. Some testing was aimed at finding out 
which options make a pair of systems work best 
together, rather than merely determining 
whether a particular option was properly imple¬ 
mented. For example, one tester set out trying to 
discover which system-level commands were 
needed to establish an eight-bit clean telnet con¬ 
nection to every other system. 

The testing lab consisted of a large room with 
three or four tables for each vendor. There were 
two main networks for testing, the "stable net" 
and the "battle net," both implemented as thin 
coax Ethernet. The stable net was connected 
though a router to the Internet so that the partici¬ 
pants could reach their home machines easily. 
The battle net was isolated and was used to test 
reaction to pathological packets. Each participant 
was asked to bring an MS-IX)S machine, and FTP 
Software provided MS-DOS-based packet sniff¬ 
ing software. When a question arose concerning 
what was transmitted on a connection, it was 
easy to get a definitive answer from a nearby 
machine. 


On the stable net, each vendor tried using the 
servers of every other vendor. Some testers sim¬ 
ply looked for basic functionality, such as logging 
in with telnet, displaying files, interrupting pro¬ 
cesses and so on. Others wrote elaborate scripts 
that exercised each ftp command. After the first 
few days, every server had been tested in a dozen 
different ways, while every client had faced a 
dozen different servers. 

The battle net was used to see how the different 
hosts responded to unusual packets. Most battle 
net tests were created by capturing a regular 
packet, then using a packet editor to create vari¬ 
ous test cases. Then another packet editing pro¬ 
gram created a list of packets, one targeted to 
each test machine. Finally, a central machine 
repeatedly transmitted the packets on this list. 

Battle net tests included ARP packets with broad¬ 
cast sources and illegal fields, IP packets with 
invalid header lengths, and strangely-frag¬ 
mented IP packets. Surprisingly, one battle net 
test revealed that half of the vendors didn't check 
the IP version number field. This is likely to cause 
trouble as new protocols are introduced. 

In addition to generating ideas for product 
improvements, the Bakeoff spurred many ideas 
for improving future Bakeoffs. The battle-net test¬ 
ing concept was refined into practice during the 
event, and one battle-net test was written from 
scratch during the week. Testers also discussed 
ideas for making multiple-packet battle-net tests, 
such as a test that could open a series of TCP con¬ 
nections and take each one through a different set 
of closing states. Detailed descriptions of the tests 
that were run will be placed on anonymous/fp 
servers by the organizers (once they catch up 
with their regular work). 

The Bakeoff was organized by FTP Software Inc., 
TGV, Inc., and Empirical Tools and Technologies 
Inc. The participating companies were BSDI, 
Data General Corporation, Digital Equipment 
Corporation, Hewlett-Packard Company, Inter- 
Con Systems Corporation, Lachman Technology, 
Inc., Mentat Inc., Microsoft Corporation, Novell, 
Inc., Tule Network Services, and Xyplex, Inc. 

All of the participants were pleased with the 
results of the Bakeoff, and planning for another 
one has already begun. For more information 
write to <bakeoff-request@tgv,com>. 
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More Old USENET Maps 


by Rick Adams 

<rick@uunet.uu.net> 

I saw the "tenth" anniversary map of USENET 
in the November/December 1992 issue of 
this newsletter. 

USENET was first announced at the Boulder 
USENIX meeting in January, 1980. The first 
software was released at the USENIX Dela¬ 
ware meeting in Summer, 1980 and there 
were about 15 sites at that time (sorry, no 
maps). 


Having UC Berkeley join the net in late 1980 or 
early 1981 was the big catalyst. The explosive 
growth started about then. 

Here are some older maps than the ones previ¬ 
ously published. Sorry, I have no idea who to 
credit (Bill Shannon maybe? Tom Truscott 
maybe?). I saved them away a long time ago. 

It's fun to note that USENET was running on the 
Internet in June 1981. 

It's weird. I still recognize almost all of the site 
names! 
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Big Iron 


by Gunter Ahrendt 

<gunter@tartarus.uiva.edu.au> 

[Editor's note: Gunter Ahrendt posts his list of the 
world's most powerful computing sites every week. 
This is the April 13,1993 posting. I find it fascinating 
that so much computing power exists.] 

BT ratings are from the NASA AMES NAS CFS 
BT Benchmark Report of May, 1992, ratios are to 
a Y-MP/1, others are Manufacturer's Peak fig¬ 
ures, ~ denotes approximations/ ? denotes 
guesses. Sites are listed in order of available BT 
figures. 

Planned installations are listed with dates follow¬ 
ing equipment in brackets. Ratings for "pro¬ 
posed" equipment and similar, i.e., [1Q94], are 
not included in the total ratings for a site until it 
has actually arrived "on-site." 

111.64 - (19-JAN-1993) 

National Security Agency, Fort Meade, Mary¬ 
land, US 

1) 4 * Cray Y-MP-C90/16-1024111.64 BT 

~-h101.65 - (26-JAN-1993) 

Cray Research, Minnesota, US 

1) 27 » Cray Y-MP/2 46.98 BT 
28) 2 » Cray Y-MP8/8-128 13.9 BT 
30) 2 » Cray Y-MP4/4-64 6.96 BT 

32) Cray Y-MP/8-32 6.95 BT 

33) Cray Y-MP8/6-64 5.21 BT 

34) 3 » Cray X-MP/2 -3.69 BT 

37) Cray 2/4-128 -3.08 BT 

38) 2 » Cray 2 -3.08 BT 

40) Cray X-MP/4-8 -2.46 BT 

41) Cray Y-MP2/2-10241.74 BT 

42) Cray Y-MP2/2-32 1.74 BT 

43) 5 * Cray Y-MP/EL2 1.65 BT 

48) Cray 2/1-16-1.54 BT 

49) Cray 2/1 -1.54 BT 

50) Cray X-MP/2-4 -1.23 BT 

51) Cray A-PP 6,720 Mflops Peak 

-+79.95 - (19-JAN-1993) 

Los Alamos National Labs, New Mexico, US, 
<dwf@acl.lanl.gov> 

1) TMC CM-5/1024 52.8 BT 

2) 2 * Cray Y-MP8/8-128 13.9 BT 
4) 2 TMC CM-200/64K -3.84 BT 


6) 2 » Cray Y-MP8/4-128 6.96 BT 

8) Cray X-MP/4-16 -2.45 BT 

9) 16 »IBM RS/6000-5601,600 Mflops Peak? 
25) Cray T-3D/256 [1Q94] 40,960 Mflops 

Peak? 

-+64.76 - (13-JAN-1993) 

Lawrence Livermore National Labs, Liver¬ 
more, California, US, <moe@jette.ner$c.gov> 

1) Cray Y-MP-C90/16 27.91 BT 

2) Cray 2/8 -12.3 BT 

3) Cray Y-MP8/8-128 6.95 BT 

4) Cray Y-MP8/8-64 6.95 BT 

5) Cray 2/4 - 6.15 BT 

6) Cray X-MP4/4-16 - 2.45 BT 

7) Cray X-MP/2-2 - 1.22 BT 

8) BBN TC2000-128 .66 BT 

9) BBN TC2000-32 .17 BT 

10) 18 »IBM RS/6000-550 1,320 Mflops 
Peak? 

28) Cray T-3D [2Q93] 40,960 Mflops Peak? 

-42.06 - (19-JAN-1993) 

Minnesota Supercomputing Center, Minne¬ 
sota, US <consult@msc.edu> 

1) TMC CM-5/544VU 28.05 BT 

2) Cray 2/4-512 - 6.15 BT 

3) Cray X-MP/4-64 - 2.45 BT 

4) Cray X-MP4/EA64 - 2.45 BT 

5) Cray Y-MP-M92/2-1024 2 BT 

6) TMC CM-200/32K - .96 BT 

7) Cray Y-MP-C90/8 [2Q93] 13.96 BT 

35.27 - (19-JAN-1993) 

Pittsburgh Supercomputing Center, Pitts¬ 
burgh, Pennsylvania, US 
<balog@bandit.psc.edu> 

1) Cray Y-MP-C90/16-256 27.91 BT 

2) Cray Y-MP/8-32 6.95 BT 

3) TMC CM-2/32K .41 BT 

4) Cray Y-MP-C90/16-512 [1Q93] 27.91 BT 

5) Cray T-3D/512 [1Q94] 81,920 Mflops Peak? 

34.86 - (lO-JAN-1993) 

European Center for Medium Range Weather 
Forecasts, Shinfield Park, Reading, England 

1) Cray Y-MP-C90/16 27.91 BT 

2) Cray Y-MP8/8-64 6.95 BT 
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-34.1 - (29-JAN-1993) 


-+10.25 - (19-JAN-1993) 


National Center for Supercomputing Appli¬ 
cations, University of Illinois, Champaign, 
US <consult@ncsaa.ncsa.uiuc.edu> 

1) TMC CM-5/512 25.4 BT 

2) Cray 2S/4-128 -6.15 BT 

3) Cray X-MP/4-8 -2.45 BT 

4) TMC CM-2 .1 BT 

-18.51 - (29-JAN-1993) 

Numerical Analysis Simulator, Ames 
Research Center, NASA, Moffett Field, 
California, US <jet@nas.msa.gov> 

1) Cray Y-MP8/8-256 6.95 BT 

2) TMC CM-5/128-32/256 6.6 BT 

3) 2 * Intel Gamma iPSC/860-128 3.82 BT 

5) Cray 2-1.54 BT 

6) Intel Paragon L-15 [1Q93] 2.6 BT? 

7) Cray Y-MP-C90/16 [1Q93] 27.91 BT 

8) Cray Y-MP-C90/16-1024 [2Q93] 27.91 BT 

-15.09 - (MAR-1993) 

National Center for Atmospheric Research, 
Boulder, Colorado, US 
<jsloan@niivot.scd.ucar.edu> 

1) Cray Y-MP/D8 6.95 BT 

2) Cray 3/2 -6.16 BT 

3) Cray Y-MP/D2 1.74 BT 

4) TMC CM-200 - .24 BT 

5) TMC CM-5 [2Q93] - .83 BT 

10.28 - (FEB-1993) 

San Diego Supercomputing Center, Univer¬ 
sity of California, California,US 
<consultant@sdsc.edu> 

1) Cray Y-MP8/8-64 6.95 BT 

2) Intel Paragon 192/16 3.33 BT? 

3) Intel Paragon 192/32 [2Q93] 3.33 BT? 

4) Cray Y-MP-C90 [3Q93] 3.49 BT 

-10.26 - (25-JAN-1993) 

Caltech,Pasadena, California, US 
<heirich@cco.caltech.edu> 

1) Intel Touchstone Delta 512 -8.04 BT 

2) Intel Gamma iPSC/860 64 1.11 BT 

3) Intel Paragon 64 1.11 BT? 

4) Multicomputer 16K/40 40,960 Mflops 
Peak? 

5) Multicomputer 512/321,024 Mflops Peak? 


Oak Ridge National Lab, Tennessee, US 
< hks@ornl.gov> 

1) Intel Paragon XP/S-35 6.07 BT? 

2) KSRl-64 3.31 BT 

3) Intel Paragon XP/S-5.87 BT? 

4) 6 » Cray A-PP [1Q93] 40,320 Mflops Peak 
10) Intel Paragon XP/S-150 [1Q94] 26.02 BT? 

8 - (31-JAN-1993) 

Arctic Region Supercomputing Center, 
University of Alaska, Fairbanks, Alaska, US 
<floyd@ims.alaska.edu> 

1) CrayY-MP-M98 8BT 

7.95 - (07-JAN-1993) 

Navy Supercomputing Facility, Stennis Space 
Center, Missouri, US 
<finnegan@invader.navo.navy.mi> 

1) Cray Y-MP8/8-128 6.95 BT 

2) Cray Y-MP2E/1-16 1 BT 

7.95 - (29-JAN-1993) 

Ohio Supercomputing Center, Columbus, 
Ohio, US <oschelp@osc.edu> 

1) Cray Y-MP8/8-64 6.95 BT 

2) Cray Y-MP1 BT 

7.57 - (29-JAN-1993) 

KFA Research Center, Julich, Germany 

1) Cray Y-MP/8 6.95 BT 

2) Cray X-MP .62 BT 

3) Cray Y-MP-M94 [1Q93] 4 BT 

-+7.42 - (03-FEB-1993) 

Center for Theory & Simulation in Science & 
Engineering, Cornell National Supercomput¬ 
ing Facility, Ithaca, New York, US 
<consult@tc.Cornell.edu> 

1) KSRl-128 -6.62 BT 

2) iPSC/860-32 .56 BT 

3) TMC CM-200/8K - .24 BT 

4) IBM ES/9000-900 2,664 Mflops Peak 

5) 16 * IBM RS/6000-550 1,173 Mflops Peak 

[800 more lines available on request] 

If you have any changes, additions or deletions to 
make, please mail them to <gunter@uwa.edu.au>. 
You can remain anonymous if you wish. 
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An Update on UNIX-Related Standards Activities 


by Nicholas M. Stoughton 
USENIX Standards Report Editor 

<nick@usenix.org> 

This report is somewhat shorter than usual, not 
least because as ;login: goes to press, the IEEE 
POSIX Spring meeting is taking place, and few of 
our regular reporters have had time to put finger 
to keyboard. Stephe Walli, standards report edi¬ 
tor for USENIX for the last year, has stood down, 
and a new fool has been found, too innocent to 
realize what he was taking on, in me, Nick 
Stoughton. 

I am unashamedly British, and if some of the 
spelling, punctuation, and use of English looks 
strange to you, that's because it is correct! Other¬ 
wise, I hope none of you notices much change in 
the style of what is reported here. Having been in 
the UNIX field since the early days of 6th edition 
(remember the Lions book?) in 1976,1 have been 
involved with almost every aspect of the operat¬ 
ing system, both from an academic point of view, 
at Queen Mary College (as it was then) of the Uni¬ 
versity of London, and latterly in a commercial 
services point of view, with Hoskyns Group, also 
in London. 

First Impressions 

However you look at it, Stephe is a hard act to fol¬ 
low. Those of you who have been following his 
comments recently on Test Methods and Lan¬ 
guage Independent Specifications will know 
what I mean! 

The next installment in these great battles domi¬ 
nated the April meeting in Irvine for many. 

As a newcomer on the scene, many people asked 
me about my first impressions of a POSIX meet¬ 
ing. Imagine two great arnaies facing each other 
across a battlefield. Rather than let each side 
attack the other till one is the clear winner, the 
whole encounter is far more formalized, more 
like a game of chess. Of course, this drags out the 
battle, but is much fairer (and of course politically 
correct)! 

How many standards committees does it take to 
change a light bulb? Forty two ... one to specify 
the mechanism for light bulb exchange, one to 
write a language-independent specification, one 
to develop test methods, a screw-cap language 


binding committee, a bayonet-cap cap language 
binding committee, a subgroup on bulb- 
exchange methodology, a working group on bulb 
disposal, then of course there's real-time bulb 
exchange... hey, this sounds like a great new area 
for POSIX! 

LIS Wars III 

The real battle of the week was the Language 
Independent Specification (LIS) issue. In January, 
an Ad Hoc Committee, chaired by Stephe Walli, 
was established to research the whole issue of 
LISs. The Ad Hoc had spent considerable time 
between the meetings canvassing opinions, and it 
was clearly a hot potato. Some countries really 
believed them a major issue, even if it took 
twenty years to get there! On the other hand, the 
real users of POSIX standards, people like you 
and me, want standards as soon as possible, and 
we want them written in a language that we can 
go ahead and use. 

The Ad Hoc met frequently during the Irvine 
meeting, and was well attended. All views were 
aired, and a consensus reached. Even writers of 
existing bindings in other languages (FORTRAN 
and Ada) recognized that the existing, non-LI, 
methods of deriving their work had worked, and 
worked well. So a very carefully worded report 
was constructed to present to the SEC. With 
Stephe chairing it, what would you expect? 

It recognized that the goals of a LIS were good, 
but that the tools were not yet appropriate for the 
task. I have lost count of the number of times in 
my working career where I have been asked, met¬ 
aphorically, to use a wrench to undo a screw. LIS 
is just another wrench, a programming language 
version of Esperanto. Indeed, although it wasn't 
suggested, if we are to write a truly language- 
independent standard, the portions currently in 
English should be rewritten in Esperanto. Actu¬ 
ally, thinking about it, I believe it was suggested 
once, but never mind. A large amount of time and 
effort has been spent in POSIX over the last three 
years trying to get LI to work, but we are still not 
much further ahead then when we started. 

The report went on to make the explicit resolu¬ 
tion to drop the requirement for LIS, allowing 
working groups to use it only if they thought it 
appropriate. It further proposed a resolution to 
provide an alternative means of ensuring seman¬ 
tic equivalence between different language bind- 
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ings. The original version, written in a specific 
programirdng language (normally C, but not nec¬ 
essarily), should contain conformance rules for 
future language bindings. 

The SEC debated this report at length. Issues such 
as what to do with existing LI work, in particular 
the POSIX.l LIS work, would need very careful 
consideration. 

The chair of the United States Technical Advisory 
Group to ISO Working Group 15 (better known as 
the WG15 US TAG), asked that the decision on 
LIS be deferred until July. WG15 itself meets in 
Heidleburg in May, and it was WG15 that placed 
the LIS requirement on the US National Body in 
the first place. If the US TAG were to present a 
unilateral fait accompli, their position would be 
much weakened. Several members of WG15 had 
made their views known to the Ad Hoc, and were 
aware of the likely outcome. It was quite clear 
that in July, the weight of opinion would be 
behind accepting the report of the Ad Hoc, and 
that SEC would cease to require LISs. The US 
TAG delegation were made aware of this. In the 
end, by the narrowest of majorities, it was agreed 
to defer the decision. Whether you view this as 
three more months, or just another three months 
depends on you point of view. 

It is clear from the falling attendances at the 
POSIX meetings (down to approx 220 from over 
300 last year) that many other people feel that far 
too little happens far too slowly at these events. 

The Little Red Standards Group 

The following text appeared anonymously on a 
notice board at the Irvine meeting during the 
"great LIS debate." It is reproduced here for your 
enjoyment. Although it represents one person's 
view, other conclusions are possible! 

“The Little Standards Group” 

Once a hard-working little standards group 
lived with a group of international standards 
organizations, WG15, SC22, and JTCl. One 
day they decided to make a standard for 
them all to share. 

"Who will help me start the standard?" asked 
the little standards group. "Not I," said 
WG15 sheepishly. "Not I," bowed JTCl. "Not 
I," grunted SC22. 'Then I will do it myself," 
said the little standards group. 

When she had cut the interface, she asked 
"Who will help me edit the standard?" "Not 
I," growled WG15. "Not I," smiled JTCl. 
"Not I," snorted SC22. "Then I will do it 


myself," said the little standards group. 

When the standard had been edited, the little 
standards group asked "Who will help me 
ballot the standard?" "Not I," sighed WG15. 
"Not I," sniffed JTCl. "Not I," whined SC22. 
"Then I will do it myself," said the little stan¬ 
dards group. 

Soon the wonderful smell of a freshly baked 
standard filled the community. "Now," said 
the little standards group, "who will help me 
use the standard?" "Not so fast," cried 
WG15. "Before we can use our wonderful 
standard, we must first have an LIS for the 
specification." "Yes!" cried JTCl. "Abso¬ 
lutely true," said SC22. "I can understand 
that," said the little standards group, "So, 
who will help me create this LIS?" "It's your 
standard, so you must do it," said WG15. 
"This is reasonable," said JTCl. "Naturally it 
is your task," said SC22. 

The little standards group worked on the 
problem for a while, but was not able to make 
progress. So the little standards group went 
back to the others. "I don't think I can do this 
LIS thing," said the little standards group. 
"And I didn't even want to do this LIS tiling 
in the first place. Even though you want it 
done, you are unwilling to help. Why should 
I do this thing for you?" asked the little stan¬ 
dards group. "You cannot call it a standard 
until we say you can," said WG15. "Regretta¬ 
bly true," said JTCl. "We agree," chortled 
SC22. 

The little standards group said 'Tine. Then it 
will not be a standard for you; it will be a 
standard for me. When you are ready, I will 
work with you to create this LIS. Until then, I 
guess you'll just have to do without." So the 
little standards group produced useful and 
portable applications, while WG15, SC22, 
and JTCl hungrily watched. 

Developing Standards in the Absence of Test Methods - 

or - What if you threw a party and nobody came? 

Many years ago, the POSIX gods decided that it 
was important for POSIX standards to have test 
assertions. The purpose of these test assertions 
was to ensure that implementations of the POSIX 
standards could be fairly evaluated by potential 
system purchasers. Unfortunately, the task of cre¬ 
ating test assertions, much like the task of testing 
software and hardware in every organization, 
was viewed as an onerous, menial task that was 
just not exciting. At the April POSIX meetings, 
the POSIX gods rescinded their test assertions 
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requirement because of considerable pressure 
from the community that develops the POSIX 
standards. In this article, I will attempt to evalu¬ 
ate the impact of this fundamental change in the 
way in which POSIX standards are developed. 
When reading this arhcle, please keep in mind 
that it is an editorial, and is one person's opinion. 
There are a number of other, perhaps better 
informed opinions in this area. With luck they too 
will write about this topic. 

Why did POSIX develop Test Methods? 

Testing is essential to determining the quality of 
any product. That is not under dispute. While 
things like Total Quality Management are cur¬ 
rently under close scrutiny to determine their 
overall benefits, the fact remains that without 
testing it is all but impossible to be confident that 
the product you are distributing will work to the 
satisfaction of your customers. 

In the open systems community, testing usually 
takes place during the development cycle. How¬ 
ever, large procurement groups (like the US fed¬ 
eral government) may require additional, post¬ 
production testing to ensure that systems con¬ 
form to open systems standards. This "conform¬ 
ance testing" is usually done via some sort of test 
suite that the procurement group has chosen. 

This need for conformance testing within the 
open systems movement has caused a segment of 
the test development community to focus on 
developing tests against open systems standards. 
In fact, the success of POSIX has caused some 
testing organizations to come into being. These 
organizations develop conformance tests against 
the open systems standards, many times in com¬ 
petition with one another for a very limited mar¬ 
ket. In order to evaluate the quality of a test suite, 
a potential test suite customer must have some 
metric for determining that the suite actually 
tests the standard in question. Hence, test asser¬ 
tions. 

Test methods are, in general, simple statements 
that describe the behavior of an interface under 
certain conditions. (Note that this is an over-sim¬ 
plification, but is generally accurate.) By agreeing 
on the test methods for a given interface, the open 
systems community in effect gives guidance to 
test suite developers as to the tests that should be 
performed to ensure conformance to the inter¬ 
face. As mentioned above, these methods can 
also be used by the community to evaluate the 
quality of the tests that the test suite developers 
produce. This is particularly useful for organiza¬ 
tions who, like the US federal government, must 
use objective metrics to evaluate products prior 
to procurement. Just as computer systems must 


be tested to see if they conform to standards, the 
tests to test the systems must be tested. 

So what's the problem? 

So far this seems pretty straightforward, right? 
Unfortunately, the model breaks down because of 
a market that is too small. While the market for 
open systems is roughly really big, the market for 
test suites is pretty small. Further, the market for 
test suites that have to be objectively evaluated 
against other, competing test suites in the same 
space is even smaller yet! Consequently, while 
the market pressure to develop open system stan¬ 
dards is very great, the market pressure to 
develop test assertions is almost nonexistent. 

What does this mean? Let's consider an example 
that typifies traditional POSIX committee pat¬ 
terns, as opposed to ideal behavior. When POSIX 
committee A starts their work, they have a base 
interface specification. There is considerable 
enthusiasm for the work, and it proceeds quickly 
(in standards terms). Eventually, the draft stan¬ 
dard is complete, and is sent out to a broader 
group of people for formal balloting and ap¬ 
proval as an industry standard. This standard 
represents an interface that is important to the 
community, and in particular important to the 
companies that funded their employees to attend 
the standards meetings and work between meet¬ 
ings to complete the document. It is, in turn, 
probably important to those companies' custom¬ 
ers, since the cost of participation is high enough 
that it usually requires some sort of higher-level 
management approval. 

At this point in the process, the members of the 
group that did the work are effectively out of the 
loop. Balloting is a process that does not gener¬ 
ally involve group activity. However, there is 
more work to be done. The standard must have 
test assertions developed. Therefore, the mem¬ 
bers of the group that have just completed work 
on the draft standard need to start developing a 
new document that is effectively a detailed 
design description of the document they just fin¬ 
ished. Moreover, this description has to be made 
in a somewhat formal manner, using stilted, pre¬ 
cise, language. On top of this, the document they 
now must develop is one that most of their man¬ 
agement and customers don't need. Conse¬ 
quently, many participants who worked on the 
initial document suspend their participation until 
there is some other task in which their sponsor is 
more interested. 

What was the solution? 

As I mentioned above, that was an example of a 
more traditional POSIX activity. Recently the 
POSIX working groups have come to grips with 
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this trend by changing their development model 
to one in wtuch the test assertions are developed 
at the same time as the interface specification. 
This results in a higher-quality specification, 
fewer changes in the specification during ballot¬ 
ing, and of course, the test assertions being avail¬ 
able in the same hme frame as the specification 
itself. That's the good news. The bad news is that 
the standard itself takes somewhat longer to 
develop in the first place, and in the end has all of 
this stuff in it that wasn't really needed by the 
majority of the standard's users. 

Other groups have addressed the problem by 
finding some industry group with deep pockets 
to do the primary development work on the test 
assertions, and then ratified the work through the 
working group process, but in a rapidly acceler¬ 
ated fashion. In the three examples of this within 
recent POSIX memory, the work has resulted in 
all the benefits of the previous example, but with¬ 
out the disadvantage of taking significantly 
longer than the development of the base stan¬ 
dard. (To be fair, the base standard in these three 
cases was also developed by an external industry 
group.) 

In both these cases the working groups managed 
to retain most of their participants throughout the 
process, and to produce standards and test meth¬ 
ods that are reasonably high-quality without 
delaying the introduction of their standards 
overly much. So, with the introduction of these 
more ideal working models, the POSIX commu¬ 
nity has discovered a way to develop the required 
test assertions, albeit with some cost to the indus¬ 
try. 

What are the implications of not requiring test 
assertions? 

So, what have we come to? Test methods are use¬ 
ful tools for improving the quality of a standard 
under development. However, test assertions are 
expensive, and the formal standard version of the 
test assertions only serves a very small commu¬ 
nity of "users" — those who develop test suites 
for open systems standards and those who need 
to do objective procurement of open systems test 
suites to use as tools for evaluating other objec¬ 
tive procurements. 

Given these assumptions, what does the POSIX 
gods' decision to no longer require test assertion 
development do to the quality or availability of 
POSIX standards? My guess: not a lot. POSIX has 
traditionally provided a useful service, and has 
not yet succeeded in making itself irrelevant. 
(Many other standards groups have.) Conse¬ 


quently, POSIX will continue to produce stan¬ 
dards for which the market exhibits a need. This 
development may, or may not, involve the speci¬ 
fication of test assertions along the way. Those 
groups that see utility in developing the test 
assertions will do so. If the market can agree on 
the need for test assertions for a given standard, 
the market may cause those test assertions to be 
developed. If a large procurement group needs to 
procure a test suite that tests a standard for which 
there are no test assertions, it may define the test 
assertions itself. In any event, the community that 
has the need will fund the development. In the 
interim, the standards the market requests will 
continue to be developed to the level of quality 
that the industry has come to expect. 

Report on POSlX.O; POSIX Guide 

Kevin Lewis <klewis@gucci.ent.dec.com> reports on 
the April 19 - 23, 1993 meeting in Irvine, CA: 

Let me say right up front that this was quite a 
productive week for the group. Our primary goal 
was to achieve in excess of 75% in our affirmative 
ballots so as to move into recirculation prior to 
the next meeting in July. The group was success¬ 
ful in achieving this goal. The chronology is as 
follows: 

• Initial number of affirmative ballots received 
was 28 out of 58, placing the percent affirmative 
at 48%. 

•The group converted 7 ballots to affirmative 
prior to the April meeting. 

• The group converted 13 ballots to affirmative 
during the April meeting. 

•This places the current percent affirmative at 
82% (48 out of 58). 

The issue of public specifications, expected to be 
a highly significant issue, proved to be exactly 
that for only a small number of balloters (5 out of 
58,3 of whom could be considered negotiable). 

The POSlX.O group conducted a Birds-of-a- 
feather (BOF) session on this issue of public spec¬ 
ifications to ensure that any balloter and any one 
else with a concern in this area had an opportu¬ 
nity have a dialogue with Dot Zero to ensure an 
effective exchange of information. Our main con¬ 
cern prior to this BOF was that the way POSlX.O 
sees public specs and their use and the way 
everyone else sees this issue might be at odds. 

It became evident after the BOF that the under¬ 
standing on this was mutual. In fact, there were a 
very small number of people (3 out of about 20 
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that attended) who had any major concern with 
this topic. 

The ISO WG15 Rapporteur and the SC22 Secre¬ 
tariat representative were present during the 
BOR I queried them on whether or not there was 
any concern expressed on this issue at their 
respective levels within ISO. They both indicated 
that each group was aware of the presence of this 
topic in the POSIX.O guide and no one had 
expressed any concern. 

Given that POSIX.O has reached the goal enabling 
a recirculation, this will be coordinated with the 
IEEE with the objective of having this next phase 
start prior to the July meeting in Denver. The 
group will be in recirculation during the July 
meeting. So our discussions will focus on possi¬ 
ble future projects, to include a guide in the area 
of Transaction Processing and an IEEE video con¬ 
ference that would serve as a tutorial about the 
use of the guide. 

Report on P0SIX.4; Real Time 

Bill O, Gallmeister <bog@lynx.com>, vice chair of the 
POSIX.4 working group, reports on the January Il¬ 
ls, 1993 meeting in New Orleans, LA: 

POSIX.4 has, for all intents and purposes, split 
into two separate groups. On the one hand, we 
have the existing "old" work of POSIX.4: POSIX.4 
itself, POSIX.4a (threads), and POSIX.13. These 
three documents are in balloting right now and 
are not, for the most part, the concern of the 
working group. On the other hand, the working 
group is busy, mostly with POSIX.4b, a proposal 
for extended real-time functionality. POSIX.4b is 
what the working group worked on in New 
Orleans. This report will briefly cover both parts 
of POSIX.4. 

What We Work On 

First, here's a brief introduction to what we do in 
POSIX.4. POSIX.4, the working group charged 
with making extensions to POSIX to support real¬ 
time applications, has a sizable stable of pro¬ 
posed standards in its estate. POSIX.4 is the basic 
real-time standard; POSIX.4a is the threads 
extension to POSIX; POSIX.13 is the profiles doc¬ 
ument that describes POSIX for everything from 
an embedded controller to a large workstation- 
based real-time system; POSIX.4b is yet more 
real-time extensions (stuff we couldn't agree to 
work on for POSIX.4); and finally, POSIX.4c is the 
Language-Independent specification and the test 
assertions for POSIX.4. 


The Old Stuff: POSIX.4. 

POSIX.4 is the base, real-time standard. This doc¬ 
ument is so close to finishing, we can taste it! On 
the last ballot, we achieved an 83% affirmative 
approval rating. By that metric, we're done. On 
the other hand, some of the remaining balloters 
are vociferous and represent large, existing bases 
of UNIX functionality. For this reason, in New 
Orleans the technical reviewers were still 
addressing the remaining objections, trying to 
remove as many of these as possible. At the close 
of the New Orleans meeting, the ballot resolution 
process wasn't completed. However, since then, 
the resolution process has been finished, and we 
have in fact sent out POSIX.4 for its final recircu¬ 
lation. Two large changes were made from draft 
13 to draft 14, along with several minor changes. 
The major changes are: 

1. The real-time files chapter has been removed 
from the document. This chapter had become 
the lightning rod for the majority of the 
remaining objections, most of which objected 
to the fact that the facility only seemed able to 
do contiguous, pre-allocated disk files. More 
capability and extensibility was desired. A 
competing proposal, for a thing called fadvise, 
has been made by one of the objectors, and it 
seems like a better solution to the whole issue 
of real-time files. We will probably be address¬ 
ing this area in future work of the POSIX,4 
working group. Unfortunately, for now there 
is no proposal in place for real-time files. I was 
personally uncomfortable with this action, it 
being late in the balloting process. At the same 
time, though, I do like the fadvise interface 
more than the POSIX.4 Draft 13 interface, and 
some of the Draft 13 facilities were, frankly, 
incomprehensible to me. Basically, I think this 
action was OK. 

2. Some of the POSIX.4 interfaces feature the 
capability to set up "something" that will 
cause the application to be asynchronously 
notified in the future. For instance, a timer 
expiration, or asynchronous I/O completion, 
both result in asynchronous notification. As of 
Draft 13, "asynchronous notification" meant a 
signal was delivered. Several objectors wanted 
the ability to replace signals with other, pre¬ 
sumably more lightweight methods of asyn¬ 
chronous notification. (Simply calling a 
function is a possibility.) Draft 14 has been 
accordingly modified to support extension to 
new methods of asynchronous notification. 
Signals are currently the only known method 
of asynchronous notification, but other, future 
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mechanisms can now be implemented in a por¬ 
table fashion under the POSIX.4 facilities. 1 am 
quite in favor of this change, as everyone 
knows there are faster ways of doing asynchro¬ 
nous notification than signals! 

In addition, there are numerous, very minor 
changes to Draft 14 of POSIX.4. At this writing, 
POSIX.4, Draft 14 has been sent out for one last 
recirculation. Draft 14 is not a complete draft; it 
is merely a set of changes from Draft 13. There 
are about ten pages of changes. The balloting 
period has already closed, and we are in the pro¬ 
cess of totaling up the responses to this last recir¬ 
culation. 

More Old Stuff; P0SIX.4a 

POSIX.4a is the threads proposal. This document 
is probably of greater interest to a lot of the 
USENIX members than POSIX.4 itself. Here's a 
shocker; POSlX.4a has gone out for a recircula¬ 
tion! After a long while in ballot resolution, the 
threads proposal was just recently sent out again. 
It should be in the hands of the balloting group 
for another recirculation before this report is pub¬ 
lished. With any luck, this recirculation will go 
more smoothly, and more swiftly, than the previ¬ 
ous two recirculations have. The good news is, 
this time, POSIX.4a is being recirculated, not 
reballoted. The previous time around, POSIX.4a 
was reballoted. What that means is, the entire 
draft was opeafor comment. In a recirculation, 
by contrast, only the changed parts of the pro¬ 
posal can be commented upon. A reballot is 
required when not enough people deliver an 
affirmative ballot. Thus, if you need a reballot, 
you're in trouble. The fact that we are recirculat¬ 
ing POSIX.4a is a good sign. 

Yet more Old Stuff; P0SIX.13 

The profiles document, POSIX.13, is currently 
still in ballot resolution. It seems to be following 
the POSIX.4a model, wherein the technical 
reviewers have very little time for technical 
review. The issues for POSIX.13 are fewer than 
for POSIX.4a - that's good. On the other hand, 
the one big issue, subsetting of POSIX.l, is still to 
be addressed. That's bad. (For those of you who 
are just learning about the POSIX.4 world, 
POSIX.13 consists of four profiles, ranging from 
supercomputer real-time all the way down to 
tiny, embedded systems. These embedded sys¬ 
tems generally run on hardware that is not capa¬ 
ble of supporting all of POSIX.l and POSIX.2 (no 
disk, no MMU, very little memory, etcetera). For 
that reason, there is a need for an embedded pro¬ 
file to call out a subset of POSIX.l: it needs a lot 
of POSIX.l, but other parts are simply irrelevant 


or impossible. Stay tuned for more information on 
how POSIX.13 is doing! 

P0SIX.4C 

Some progress has been made towards a language- 
independent specification for POSIX.4. However, 
given the current instability of the whole LI thing, I 
wouldn't be surprised if we were able to drop this 
work later on. For now, work continues on LI. 

New Stuff; P0SIX.4b 

POSIX.4b is a collection of fairly exotic stuff: time¬ 
outs on blocking functions, direct application access 
to interrupts and different types of memory, spo¬ 
radic server scheduling, and so on. The facility that 
is of interest to the mainstream community here is a 
thing called spawn. Spawn combines fork and exec 
into a single call that spawns a new process. This is 
useful for systems (see above) that cannot support a 
separate fork (because they have no MMU for dupli¬ 
cating an address space), but which can support sep¬ 
arate processes (because they have enough physical 
memory for it). Spawn is interesting to the main¬ 
stream community because, in general, a fork is fol¬ 
lowed by an exec anyway. Spawn would be a nice 
way of combining things. 

Other interesting work is devctl. Devctl is really ioctl, 
but we had to rename it so as to not break existing 
systems. 

During the week in New Orleans, small groups 
addressed various issues in the chapters of 
POSIX.4b. An interface for various sorts of typed 
memory (static RAM, different buses to access the 
same memory, and so on), was part of the proposal, 
but due to lack of interest and commitment in this 
proposal it was removed from the proposal. Other 
changes were less drastic. We hoped, at New 
Orleans, to take the document out for balloting after 
the Irvine meeting. I personally have my doubts that 
this will happen. I think it will take a couple more 
meetings to mature the POSIX.4b functionality suffi¬ 
ciently. On the other hand, POSIX.4b has been sub¬ 
stantially written (in Language Independent form 
plus C bindings, even!), so I could be mistaken. 

Report on P0SIX.9; FORTRAN Bindings 

Michael J. Hannah <mjhannah@sandia.gov>, chair of 
POSIX.9 reports on the January 11- 15, 1993 meeting in 
New Orleans, LA: 

The POS1X.9 (FORTRAN bindings) group, though 
sparsely attended, did meet in January and made 
progress towards their next project. While other 
IEEE standards have been drafted by three people, 
this is uncommon for POSIX. A committee of such 
small size implies a very significant reliance on the 
ultimate balloting group. There is nothing wrong 


30 ;login: May/June 1993 



with a small group doing the draft, but before 
such a draft becomes a standard it must be 
reviewed and examined by a much larger, repre¬ 
sentative, balloting group. While there may be 
nothing improper or illegal with this approach, I 
would certainly like to see more participation in 
our meetings. 

IEEE Std POSIX.9-1992 is approved and was 
available for purchase at this meeting. This stan¬ 
dard completely defines how to access all func¬ 
tionality of ISO/IEC 9945-1:1990 from FORTRAN 
77, as well as defining a generalized way to access 
any operating system structure and defining 
byte-stream I/O for FORTRAN 77. Since FOR¬ 
TRAN 77 is essentially a subset of the new For¬ 
tran 90 standard, IEEE Std POSIX.9-1992 is 
completely usable in a Fortran 90 environment. 
Like any standards committee that just com¬ 
pleted a standard, the committee discussed how 
to convince vendors to implement this standard, 
and how to convince users to demand this stan¬ 
dard from the vendors. 

Actual work was begun on draft 0 of the next 
project for this committee, POSIX.19, which is a 
binding between the Language Independent 
Specification (LIS) of POSIX.l and the new For¬ 
tran 90 language standard. This Project Authori¬ 
zation Request (PAR) was approved by the IEEE 
standards board in Sept 1992, though approved 
over a year ago by the SEC. Part of the delay was 
ensuring complete liaison with X3J3, the FOR¬ 
TRAN Language committee. At their August 
1992 meeting, the X3J3 approved an official reso¬ 
lution endorsing the scope of the POSIX.19 PAR 
and agreed to active liaison with the POSIX.9 
committee. This is significant since the POSIX.19 
PAR includes in its scope the ability to define 
extensions to the base language standard of For¬ 
tran 90. One of the major unresolved objections in 
balloting IEEE Std POSIX.9-1992 was that many 
of the functions could have been defined as sim¬ 
ple extensions to the base standard syntax. For 
example, mode bits could be included as an 
extension to the FORTRAN OPEN statement, etc. 
Such an approach is planned for the POSIX,19 
work. 

The committee began by discussing the overall 
approach to the new work. In addition to examin¬ 
ing the new language features in Fortran 90, the 
committee discussed how this new binding 
should relate to the POSIX.l LIS and its compan¬ 
ion POSIX.l C binding. While this POSIX stan¬ 
dards body is focused on portability of 
applications, as an end user I am particularly con¬ 
cerned about portability for application writers. 
Whether to point to the LIS or point to the "his¬ 


torical practice" of C is a contentious issue. For 
example, the LIS describes a procedure called 
change_f ile_mode , while the traditional C 
function is called chmod . In IEEE Std 1003.9-1992, 
because any function/subroutine name in FOR¬ 
TRAN 77 was exposed to the loader, and since the 
IEEE Std 1003.9-1992 routine to change file mode 
had to be slightly different than chmod, we had to 
give it a dishnct name, PXFCHMOD. Because of 
the new features of Fortran 90, module names 
used by an application are not necessarily 
exposed to the loader. Thus we could now call the 
Fortran 90 routine chmod without fear of conflict 
with a different C library routine of the same 
name. Using chmod as the name is intuitive to any 
programmer coming from the C world, but is not 
intuitive to a strictly FORTRAN programmer. 
While the argument in this example may be 
stronger for chmod since there is also a POSIX.2 
command by that same name, such an argument 
does not apply to all POSIX.l functions. If you 
really believe in the concept of the LIS, and espe¬ 
cially if the new C binding is "thin," then a name 
that is the same as the LIS change_f ile_mode 
nught be more appropriate. A Fortran 90 bind¬ 
ings reader should need at most the POSIX.19 
binding and the POSIX.l LIS. However, many LIS 
names are more than 31 characters, so some map¬ 
ping may be required, or an extension to Fortran 
90 to recognize uniqueness in names longer than 
31 characters. This seems to be something like a 
religious issue, where parties on each side are cer¬ 
tain that their position is correct, and the only 
intelligent position. The current committee 
default is to use the long LIS names, not the famil¬ 
iar C names, but this may change. 

One item of interest is that new constructs in For¬ 
tran 90 seem to permit the binding to be com¬ 
pletely specified as Fortran 90 code fragments. 
Whether the IEEE and ISO document structures 
could be accommodated by this is unclear. For an 
implementation, you would like to give an elec¬ 
tronic copy of the binding (code fragments) to the 
implementors so they could simply add the rest 
of the code necessary on their implementation. 
Since the code fragments completely define the 
application interfaces, this would be a boon for 
everybody However, such a scheme also raises 
the question among the lawyer folk as to what 
this would mean with regard to the IEEE copy¬ 
right of the binding. 

Finally, the committee was actively involved in 
the hot debate concerning whether the POSIX 
Executive Committee should rescind its manda¬ 
tory requirement for base POSIX standards to be 
developed as Language Independent Specifica¬ 
tions (LIS). As a language binding committee we 
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are viewed as the direct beneficiaries of the work 
to produce an LIS. The members of the bindings 
committee of both the POSIX.5-Ada and 
POSIX.9-FORTRAN have strong opinions on this 
issue. 

The POSIX.9 committee is scheduled to meet the 
first three days of the April POSIX meeting. 

Report on P0SIX.18: POSIX Platform Environ¬ 
ment Profile 

Paul Borman <prh@cray.com> reports on April 19 - 
23,1993 meeting in Irvine, CA: 

The Reduction Continues 

At the April meeting in Irvine, the POSIX.14 
group dedicated one day to the POSIX.18 Draft. It 
was much easier to work on the draft this time, 
mostly due to its reduced size. As before, the 
major work done on the draft was reducing the 
number of words. 

First of the areas we attacked during this meeting 
was the introduction and scope. We decided that 
even though the content was basically hidden in 
there someplace, we would do best by just rewrit¬ 
ing the introduction and scope instead. 

The next section of the document looked at was 
the definitions section. After reviewing the defi¬ 
nitions of conformance, we moved them to the 
conformance section of the document. We also 
removed several definitions that were either 
defined in one of the base-level standards we ref¬ 
erence, or were actually simply definitions of 
English words, such as "portability.'' 

In the actual normative text, we moved some of 
the pieces in the "Language Interoperability" sec¬ 
tion to our "Coherency" section. This was done to 
clarify and not change content. The only actually 
substantial change was to remove the FIPS 151-2 
requirements fores 7 , CSS, CSTOPB, PARODD 
and PARENB, which were added at the last meet¬ 
ing. It was brought to our attention that this was 
required by NIST to facilitate their RS-232 loop 
back test. We decided it was not appropriate for 
this profile to require a particular hardware inter¬ 
face. 

We had some discussion on the Fortran Language 
option when we realized that as the document 
stood we referenced FORTRAN 77, specified For¬ 
tran 90 and required a binding to FORTRAN 77 
(POSIX.9). Although we are not sure what to do 
for the final draft, we are sure that it should be 
consistent. The issues include: 


1. POSIX,9 currently refers to an ANSI standard 
(FORTRAN 77) and is not an international 
standard. 

2. The International standardized version of FOR¬ 
TRAN is Fortran 90, which is not as widely 
used as FORTRAN 77, 

3. This profile is intended to be forwarded to ISO. 
The options that we see ahead of us include: 

1. Drop the Fortran Language option (not desir¬ 
able). 

2. Have two Fortran Language options (though 
only the Fortran 90 option would probably 
make it through ISO. 

3. Wait for a resolution between POSIX.9 and For¬ 
tran 90, then do what seems appropriate. 

Finally, we actually removed all references to test 
methods from the document. The SEC has 
rescinded the requirement for test methods and 
we had been spending too much time on it with¬ 
out having satisfactory results. This also saves 5 
full sheets of paper (10 pages). 

Once the new editing job has been done, we will 
probably be basically ready to go to ballot, but we 
will have to wait because our document depends 
on both POSIX.4a and POSIX.la. 

Report on P0SIX.19: Fortran-90 Bindings 

Michael}. Hannah <mjhannah@sandia.gov> chair of 
POSIX.19, reports on the April 19 -23, 1993 meeting 
in Irvine, CA: 

This was an important meeting for anyone fol¬ 
lowing the subject of FORTRAN language bind¬ 
ings to POSIX. After two years of effort to drum 
up interest in a Fortran 90 binding, the POSIX.9 
Working Group proposes to call it quits. The few 
folks who are left believe that there is an insuffi¬ 
cient body of knowledge, practice, or users of 
ISO/IEC 1539:1991 (Fortran 90) to sustain the 
effort of producing a POSIX binding at this time, 
especially in light of a number of outstanding 
technical issues. Many of these issues concern 
trying to determine how best to use the new fea¬ 
tures of the Fortran 90 language in a POSIX bind¬ 
ing. However, in a spirit of one last time, the 
Working Group postponed until July the final act 
that would disband the Working Group. At the 
July POSIX meeting, the Working Group will 
meet for one day only, Monday, July 12. Barring a 
large turnout desiring to retain the Working 
Group, the Working Group will recommend that 
the executive comnuttee of POSIX withdraw 
sponsorship of the Fortran 90 binding project and 
disband the group. 
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The group is circulating a draft of a final report 
among members who have participated in the 
effort so far, and will present the completed final 
report at the July meeting. 

The probable demise of this working group raises 
several questions about POSIX and language 
bindings: 

1. How many different languages are likely to 
bind to POSIX? If this is only a few, does this 
imply that POSIX is less valuable? 

2. Is POSIX just for C and Ada, and all other lan¬ 
guages should simply figure out how to call 
system routines in those languages? Does this 
make those other languages second class citi¬ 
zens in a POSIX world? 

3. If there are to be future language bindings, 
should the IEEE with its POSIX steering com¬ 
mittee sponsor that work, or should the com¬ 
mittees that define and standardize the 


language (usually part of ANSI X3) define 
those bindings? There is some discussion of 
Modula 2's and COBOUs doing this, and the 
Fortran 90 project might be resurrected in X3J3 
rather than IEEE POSIX. Is this good or bad? 

4. Is the lack of interest in Fortran 90 simply a tim¬ 
ing issue due to the lack of widespread access 
to Fortran 90 compilers, or is it due to a lack of 
interest in Fortran 90 itself? or is this just 
another victim of the economy? 

There are undoubtedly a wide variety of reasons 
why there is insufficient support at this time for 
this work. There could be considerable debate 
over which reason was the most significant. Some 
would argue that the group should never have 
tried to start. However, it is clear that there is 
inadequate support to continue. I believe it is the 
responsible thing to disband this working group. 
If you don't agree, now is the time to speak up. 


Automatic Information Server 


The Association now has a mail server that will 
answer requests received through electronic 
mail. Information is available about USENIX 
membership, conferences, and publications. 

Please send all requests to: <almanac@usenix,org> 

To receive the Almanac Primary Services Cata¬ 
log, the body of your mail message should con¬ 
tain only the line: 

send catalog 

This catalog outlines accessible information 
about the USENIX Association's services. You can 
get more detailed listings for sub-topics in each 
service catagory by sending the line: 

send service catalog 

where "service" is one of the primary topics 
listed below. Thus: 

send conferences catalog 

will result in your receiving a listing of available 
announcements for upcoming USENIX Confer¬ 
ences and Symposia. 

All files are in plain text format. 

Questions, comments, suggestions: please con¬ 
tact <almanac-admin@usenix.org>. 


Service: conferences 

Description: Conferences contains all the current 
announcements for USENIX Conferences and 
Symposia. This includes all available calls-for- 
papers and registration information (technical 
sessions, tutorials, fees, and accomodations) for 
upcoming events. To get conferences catalog: 

send conferences catalog 

Service: publications 

Description: Publications contains all ordering 
information for our conference proceedings, back 
issues of our quarterly technical journal, Comput- 
ing Systems, as well as publications announce¬ 
ments, and calls-for-papers for special issues of 
Computing Systems. To get publications catalog: 

send publications catalog 

Service: membership 

Description: Membership contains information 
about the USENIX Association, the System 
Administrators' Guild (SAGE), and an application 
form. To get membership catalog: 

send meinbership catalog 
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The Bookworm 


by Peter H. Salus 

<peter@uunet.uu.net> 

Back to Basics 

The last few weeks have seen a flood of "begin¬ 
ning" books hit my mailbox. Though most read¬ 
ers of this column won't need them, Tm sure that 
many of you get asked for pointers (or are look¬ 
ing for possible textbooks). 

Among these books are three one-volume guides 
to UNIX: Modern UNIX, UNIX for Programmers and 
Users, and A Student's Guide to UNIX. While the 
first and last of these are useful, I found Graham 
Glass' "complete guide," less so. (The reason for 
this may be the publisher's fault, not Glass': 
Bach and Leffler, McKusick, Karels & Quarter- 
man each run to 400-500 pages. The notion that 
we can have a "complete guide" in just over 600 
is a bit silly. Glass' early chapters, on UNIX philos¬ 
ophy and UNIX for nonprogrammers, are quite 
well-done. The reference list [of only 19 items] is 
just weird in form and content.) 

Southerton's Modern UNIX is less pretentious, but 
still leaves me with an unhappy feeling. I think 
this was because Southerton, who is Product 
Reviews Editor for UNIX World, is trying to do too 
much in a small compass. The blurb tells me that 
this volume is for "people who need to become 
'power users' quickly." It ain't. 

Lest all of you think that Tm just a grouch this 
month, let me set up as Exhibit A Hahn's Student's 
Guide to UNIX^. At just over 600 pages, this is 
nearly the same size as Glass' book, but it is a 
model of presentation and limitation. For exam¬ 
ple, .forward files are listed in the chapter on dot 
files in general and considered part of mail. Nei¬ 
ther Southerton nor Glass think forwarding is 
useful enough to talk about. Hahn's chapters on 
shells are quite good. He also appears to be the 
only one of the three authors who has heard of 
bash and Zsh. Without being overly detailed, let 
me also compliment Hahn for having the good 
sense to include a section on games. While we all 
know that (a) the person in the next office wastes 
his/her time playing games, we also know (b) 
that we have never played games. This is the 

1. Look for McGraw Hiirs 20% discount offer 

on selected titles for USENIX members in the 

July/August issue of ;login: 


perfect book for newcomers to UNIX: whether 
they are raw newcomers or transferees from 
some other OS. After you've zipped through 
OPlA's wonderful "Single Session Overview," 
Hahn's is the book to turn to. And a compliment 
to McGraw Hill: the book is well laid-out and the 
inside rear cover features a "Quick Index" to 
UNIX Commands. 

Yet more Internet books 

Prentice Hall has taken over the publication of the 
"Internet Information Series" from SRI. The vol¬ 
umes I've got are Internet: Getting Started and 
Internet: Mailing Lists. Getting Started is a useful 
volume that folks intending to use the Clinton- 
Gore information highway should acquire. I see 
a period in the near future when folks who know 
next to zilch about computing/routing/send- 
mailcf files/uucp will be sending notes to their 
friends and family and trying to glean informa¬ 
tion from remote sources. As more and more 
folks who have trouble setting the time on their 
VCRs get access, books like this become more 
important. Mailing Lists contains a list of lists of 
over 800 mailing lists. I don't know how many 
such lists there are. I do know that only two of 
the five noncomputing lists I'm on appear (med- 
text, gerling, and disc-nordic are missing). I hope 
the score will improve in the future: the editors 
do request additions and corrections. 

Insecurity 

In August 1988, Matt Bishop chaired the first 
USENIX Security Workshop in Portland, OR. He 
also chaired the second one there in 1990. The 
third Security Workshop was held in Baltimore 
last September, cohosted by CERT, and chaired by 
Ed DeHart. If Ferbrache and Shearer had been 
aware of these, they might have mentioned Dan 
Klein's work on password-cracking (since he also 
gave a paper at the UKUUG in 1990, they might 
have noticed that). 

I am going to try and control myself where Fer¬ 
brache and Shearer's sloppy yet expensive book 
is concerned. I hesitate to call them plagiarists, as 
some items might be inadvertent: like printing 
nearly all of Gene Spafford's Purdue report on the 
Internet worm, without a note at beginning nor 
end that this isn't their work (Appendix A); or 
"paraphrasing" much of Farmer & Spafford's 
paper on COPS from the Anaheim (1990) USENIX 
Proceedings. 

But let's ignore the stuff that ain't theirs: it's good 
stuff, anyway. But what about ignoring a vast 
amount of other material: Bill Cheswick's, or 
some of the Kerberos things other than Steiner et 
al., or de Alvare, or some of the European work. 
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Moving right along, what I meant as sloppiness 
may be exemplified by on the one hand, the 
chapter on CERT without an address in the list of 
"Contact Addresses;"and, on the other, by the 
fantastic contempt that the authors seem to have 
for peoples' names (Merrit for Merritt; Mockpet- 
ris for Mockapetris [several times]; etc. Enough, 
enough. 

Not recommended. If you need a security book, 
buy Curry or Garfinkel & Spafford. 

Take Vitamin C 

To get rid of the bad feeling that Ferbrache and 
Shearer give you, get a copy of the second edition 
ofTizzard's book on C. I liked the first edition of 
this back in 1987. But that was pre-ANSI. Tiz- 
zard has gone ahead and really rewritten his 
book in a useful and practical way. This one is rec¬ 
ommended. But it's not for beginners. 

TLI and Sockets 

Mike Padovano has churned out a massive book 
that's decidedly not for beginners. It is, however, 
the full answer to a question in Vol. I of Comer's 
Internetworking ... series: "What are the major con¬ 
ceptual differences [between TLI and sockets]?" 
Half of Comer's answer is in Vol. Ill [the BSD/ 
sockets part]; most of Padovano's 500+ pages are 
devoted to TLI. I have to admit that he's also got 
a respectable amount of BSD material, but it 
appears to be in there only to show how much 
better (and better-integrated) SVR4 TLI is. (As 
SVR4 incorporated sockets into the AT&T code, 
one can understand this.) 

Don't get me wrong: this is a very good book. I 
think that it will end up on most shelves next to 
the Comer [& Stevens] trilogy (soon to become a 
tetralogy as C&S keep up with Marshall Rose in 
volume production) and Rich Stevens' network¬ 
ing book. But as I said, this is not for the unini¬ 
tiate. 

Padovano has a good discussion of TCP/IP 
inside SVR4, including the implementations of 
ftp and telnet (Chapter 3). He talks about the 
mapping of the socket routines into TLI routines, 
referring to his chapter 10 for full details. And 
then he gets into ports. What would the tyro 
make of: 

Every system offering the ftp service has it 
available on port number 21. The TCP/IP 
specification states that port numbers over 
255 are not reserved. However, SVR4 
restricts these port numbers by using the fol¬ 
lowing BSD conventions: Port numbers 1 
through 1024 are considered "privileged 


ports." Your application can use these ports 
only if your effective user-id is 0. (p. 65) 

There's a lot more. Flipping to chapter 10, 
"Applications using Sockets" (pp. 449-536) is, 
in fact, helpful. Padovano clearly knows his 
stuff. The only problem with this book, how¬ 
ever, is that not only are there a lot of applica¬ 
tions using sockets around, there are a lot of 
folks who prefer BSD to USL (and I am not 
referring to legal strife). Relegating BSD mate¬ 
rial to a few scattered remarks and the final 
chapter (though a long one) does a disservice. 
Padovano's prejudices show through. 

On the other hand, Padovano's sections on the 
architectures and goals of RFS and NFS are 
really very fine (Chapter 5). The two brief 
expositions on goals (pp. 133-134 and 147) are 
the answers to all those interminable discus¬ 
sions of which is better, a skillet or a pencil. 
Check it out. 

The X Window System 

Issue five of The X Resource contains the Pro¬ 
ceedings of the 7th Annual X Technical Confer¬ 
ence (Boston, January 1993). I'm not going to 
itemize papers, but if you work with/program 
in X and don't get this quarterly, you ought to. 

I hope that with Bob Scheifler stepping down 
from the X Consortium, the Conference and the 
Resource don't vanish, too. 
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Numerical Recipes in FORTRAN 


Numerical Recipes in FORTRAN; The Art of 
Scientific Computing (2nd ed.) by William H. 
Press, Saul A. Teukolsky, William T Vettering, 
Brian P. Flannery. Cambridge University Press, 
1992.ISBN 0-521-43064-X. 963 pp. 

Reviewed by Henry Spencer 

<henry@zoo.toronto.eclu> 

You say this doesn't sound like a UNIX book? 
Especially since the programs are written in a 
revolting language that's basically a relic of the 
past? So what on earth is a review of it doing in 
;login:, you say? 

True, this is not a UNIX book, and it's on a subject 
- numerical computing - that most UNIX systems 
programmers would walk miles to avoid. How¬ 
ever, now and then you don't get a choice. This is 
one of those rare books that is both an authorita¬ 
tive overview of a field and a down-to-earth prac¬ 
tical reference; it is the book you want to have 
handy just in case you do need to know how to do 
some numerical computing. 

Heaven knows. I'm not much into the numerical 
stuff myself, but when I suddenly needed to write 
a numerical program, I happened to have the pre¬ 
vious edition of this book on my shelf, and it told 
me everything I needed to know. I originally 
thought I had a reasonable idea how to tackle the 
problem, maybe not great but okay. When I read 
the relevant chapter, one of the first things in it 
was a discussion of why my intended algorithm 
was a bad choice. The final program was far supe¬ 
rior to anything I could have come up with on my 
own. When the new edition of the book came out, 
I considered it a smart investment, and it's 
already paid for itself. 

If you came through a computer science back¬ 
ground, like me, you probably have less-than- 
fond memories of the numerical-analysis course 
that CS departments like to inflict on their vic¬ 
tims. Let me assure you that this book is nothing 
like that course or the textbook you used. There is 
a little bit of theory here and there, because the 
book spends just as much (if not more) paper on 
explaining the algorithms as on presenting the 
code for them. However, the emphasis is on prac¬ 
tical advice: what works and what doesn't, what 
precautions to take, how the various methods 


compare on accuracy and speed. The book is full 
of references for further reading, but its own dis¬ 
cussion concentrates firmly on the most useful 
methods for people who have to get some actual 
computing done. 

While Numerical Recipes does cover some of the 
same ground as a traditional numerical-analysis 
course, it also ranges further afield. It talks about 
systems of linear equations, numerical integra¬ 
tion, root finding, integration of differential equa¬ 
tions. It also covers evaluating various unusual 
functions, generating random numbers (includ¬ 
ing a simple routine to "clean up" the output of 
the rather poor random-number generators 
found in typical subroutine libraries), Monte 
Carlo methods, sorting, statistics and modeling 
of data, the Fast Fourier Transform, etc. There's 
even a routine to compute the phase of the Moon, 
in case you really want your software to depend 
on it! 

Overall, the discussion ranges from quite elemen¬ 
tary to moderately advanced. The book can't 
introduce you to everything; in some areas, you 
need a general idea of what's going on before the 
book's discussion makes sense. In general, 
though, it does a commendable job of filling in 
the background of the topics it discusses, which is 
important if you don't know very much about a 
subject and need to decide which method to use. 
The language throughout is informal and read¬ 
able; the authors are programmers, not mathema¬ 
ticians, and it shows. There is even occasional 
humor: "If you know what bubble sort is, wipe it 
from your mind; if you don't know, make a point 
of never finding out!" 

The one criticism of this book that I've heard 
occasionally is that its treatment is sometimes too 
simplistic, and you can get into trouble with it. 
This is usually accompanied by comments, or at 
least implications, like "if you don't know what 
you're doing, you have no business trying to do 
numerical computing." That's all well and good, 
but a lot of us have to try anyway. Expertise in 
numerical computing is relatively scarce and 
expensive, either in money (to hire it) or time (to 
acquire it yourself), and all too often you simply 
cannot afford it. This book is not as good as ten 
years of training and experience in numerical 
computing, but if you don't happen to have such 
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expertise on tap, using this book is a whole lot bet¬ 
ter than digging out your old numerical-analysis 
textbook or blundering ahead on your own. 

In case I haven't made it clear enough already, I 
highly recommend this book. If you ever need to 
do any numerical computing on short notice, you 
will be very happy that you bought it. It's a price¬ 
less reference. 

At this point, I should explain that this book 
exists in several different versions. Folks who 
don't like FORTRAN may prefer this book's 
brother: Numerical Recipes in C, 2nd ed. The old 
first edition, still very useful though not as good 
as the second, also came in Pascal and BASIC ver¬ 
sions, and those are still available. There are also 
example books (showing how to use the routines 
from the main books), and the code is available 
on floppies. 

So why did I get the FORTRAN version, given that 
I'm primarily a C programmer and don't much 
like FORTRAN? Well, the authors of this book are 
FORTRAN programmers first and foremost, and it 
shows in their C code. Td rather read the pro¬ 
grams in the original and not have to puzzle over 
odd idioms created by the translation. FORTRAN 
is not that hard to follow, especially since the sec¬ 
ond edition of the book formats the programs for 


readability rather than worrying about whether 
FORTRAN compilers would approve. For exam¬ 
ple, the programs are mostly in lowercase letters 
rather than the traditional EVERYTHING IN 
UPPERCASE style that makes FORTRAN so pain¬ 
ful. 

But isn't it annoying having to rethink the algo¬ 
rithms to express them in C? Well, yes, but this 
brings up one final topic that I ought to mention. 
The programs in this book and on those floppies 
that I mentioned are not public domain or freely 
redistributable. Buying the book (as opposed to 
borrowing your friend's copy!) does give you rea¬ 
sonable rights to personal use (as explained in a 
"Legal Matters" preface), but more serious use 
needs to be licensed. If you don't want to hassle 
with that, you can't use their code (or a direct 
translation). But the real value of this book is in 
the algorithms, not the code, and it's only the 
code that's copyrighted. 

I haven't bothered buying the floppies. The book 
is enough. I can handle the programming side of 
it, if I know what I should be programming. When 
it's something numerical. Numerical Recipes is 
where I go to find out. 


Inside Windows NT 


Inside Windows NT by Helen Custer. Microsoft 
Press, 1993.385 pp. ISBN; 1- 55615-481-X.Soft- 
cover, $24.95 

Reviewed by Bob Birss 
SunPro 

<bob.birss@sun.com> 

Lots of people want to read this book. Lots of peo¬ 
ple have already bought it. It is, after all, "the 
inside story behind the design, philosophy, archi¬ 
tecture, and future of Microsoft's next generation 
operating system," as the blurb on the inside of 
the two-part front cover tells us. But will those 
people find it satisfactory? I doubt it. 

Inside Windows NT tries to be almost all things to 
almost all people - it is "not written for operating 
system designers.., [but] for the rest of us, those 
who know something about computers and who 
want to understand the internal design of this 
system." A tall order, and one which it doesn't 
quite fulfill. 


The book invites comparison to Tracy Kidder's 
Soul of a New Machine, and, in fact, Custer says she 
reread that book "for inspiration and a sense of 
kinship." And, she says, "the construction of Win¬ 
dows NT was a software version of the hardware 
construction documented in Kidder's book." I'm 
sure that's true. But this book isn't the story of the 
development of NT, except for occasional men¬ 
tions that "this person designed that" or "that 
person, who spent years at DEC, was the architect 
of this." These glimpses are annoying, because 
they're not enough for the person who really 
wants to know the story of NT development and 
too much for the person who simply wants tech¬ 
nical details. 

The book also invites comparison to Maurice J. 
Bach's The Design of the UNIX Operating System, 
Both books contain a wealth of technical detail. 
And Bach is addressing a fairly wide audience: 
students, systems programmers, and "program¬ 
mers on UNIX systems" (p. xii). But Bach's book 
is more satisfying, perhaps because it's about a 
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system that had actually been shipped. 

That NT hasn't shipped yet is probably one of the 
biggest reasons why this book is unsatisfying. It 
is certainly hard to be accurate about the precise 
details of a system months before it ships. And it 
is certainly a good marketing ploy to have 
released this book ahead of shipment. But if you 
want to find out what's really going on inside 
Windows NT, it won't be easy to do so from this 
book. 

Take, for example, the point made by David 
Fiedler in his article "Microsoft Sets Its Own Stan¬ 
dard" in the March 15 Open Systems Today. Fiedler 
notes that Microsoft has recently been conducting 
a campaign to convince us that NT is "open" and 
has an "open architecture." But, as he says, if we 
consult Custer's book, we see that the term "open 


architecture" refers only to interoperability across 
networks (p. 304) and that openness per se is not 
listed as one of NT's design goals (p. 5), though 
compatibility "with existing Microsoft systems" 
is. 

That sort of inconsistency might bother you, too, 
if you're one of those folks that the back cover 
tells us is "making decisions about how to pro¬ 
ceed into the future of personal computing." You 
might want a detailed comparison to UNIX, for 
example. You won't find it. You might want a 
description of what hardware you'll need to run 
NT. You won't find that, either. 

There is certainly a wealth of technical detail in 
this book, and many excellent illustrations. But it 
feels like only half the story. Perhaps someone is 
already at work on "Outside Windows NT." 


mix Power Tools 


UNIX Power Tools by Jerry Peek, Tim O'Reilly, 
Mike Loukides. O’Reilly & Associates, 1993. 
ISBN: 0-553-35402-7.1149 pp. $59.95 (49.99 
(that’s pounds] in UK) 

Reviewed by Rob Kolstad 

<kolstad@hsdi.com> 

The first thing one notices about UNIX Power Tools 
is its size. It is large. It is hefty. It weighs in at 
about four pounds (even in paperback). It's 
almost two inches thick. There's a lot of it: 32 
pages in the table of contents alone; 1,059 pages of 
terrific text, an 11 page glossary, and a 47 page 
index! 

Bigger is not always necessarily better, but in this 
case bigger is fantastic. 

If you have ever been the guru at a site or the "hot 
shot" system administrator then you've 
answered dozens of user questions like "How do 
I move 20 lines from here to the middle using 
y/?", "How do regular expressions work?", "Why 
does my shell start so slowly?" and dozens more 
- the answers to which are learned only in the 
school of hard knocks (along with the subtle com¬ 
plexities behind the first-order answers). This 
book answers those questions and hundreds 
more. 

Want a quick intro to source-control? See pages 
366-375 (both SCCS and RCS). Want to be an 
expert on the find command? See page 302 and 
303. Want to see clever shell tricks you can use 


today? - check out Chapter 11. The list, while not 
endless, is nearly so. 

This book has all the "tricks" in it that one accu¬ 
mulates after years of trial-and-error in learning 
how to get real leverage out of using UNIX-style 
systems. If you're a user who is not intimidated 
by UNIX's building block philosophy, this is the 
book for you. It includes tricks and explains their 
derivations. It includes warnings on how the 
tools will abuse you if misused (warnings in 
boxes with a lovely rendering of a screw). It even 
includes a CDROM wdth all the scripts from the 
book! Who could ask for more? 

I liked the way the authors gave not only their 
own points of view, but also quoted those who 
dissented (whether from personal correspon¬ 
dence or from the net). I particularly enjoyed 
their typographical conventions: the margins 
include cross-references and CDROM-references; 
they use blue type inside the text for cross-refer¬ 
ences. This book is clearly lovingly crafted and 
must represent years of gathering tricks, tips, and 
hints. 

I've asked a dozen people how they liked the 
book - the answer was universally positive. I love 
the book. I learned a couple tricks on my first 
browse through it. If you use UNIX frequently, 
you can increase your leverage the first time you 
read one of the book's 54 chapters. I keep it in my 
reading room for those times when one wishes to 
check out a quick 2-3 minute section of a book or 
magazine. 
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If you're a UNIX guru, you can probably learn 
new things too. And if you'd like to be a UNIX 
guru, this is the book for you. If you're intimi¬ 
dated by command line and the "UNIX Philoso¬ 
phy," this book will seem esoteric; skip it in favor 
of something more your flavor. 


Obtaining GNU Software 


Is it worth the price? It is a good deal on a price- 
per-pound of book basis or price-per-page. It is a 
great deal if you use the CDROM that's included. 
But most of all, it is a fantastic deal if you want to 
learn to leverage your time and become more 
productive in your work. Rush out to buy this 
one - it's great! 


by <gnu@prep.ai,mit.edu> 

The GNU (GNU's Not UNIX) Project of the Free 
Software Foundation (FSF) is developing a com¬ 
plete UNIX compatible software system with 
freely redistributable source code. The rationale 
for GNU is explained in the GNU Manifesto. Cop¬ 
ies are available in the GNU Emacs'Manual and 
sources, or ask<gnu@prep,ai.mit.edu>. 

You can get GNU software from (or with) others, 
by ftp on the Internet, and by uucp from uunet 
and other sites. You can also order the software 
from the FSF. Ask gnu@prep for details. 

In the long run, it makes sense to choose FSF as 
your source for distribution copies of GNU soft¬ 
ware, because only that way significantly sup¬ 
ports GNU software development. The other 
ways you can get copies provide little or no 
funds for free software development. 

FSF also gratefully accepts donations of any size; 
as FSF is tax exempt (in the US), your donations 
are tax-deductible. But usually the easiest way to 
support the FSF is by ordering a software distri¬ 
bution. 

Like listener-supported public radio, FSF 
depends on you to continue our work. If you use 
GNU software, and you have not supported FSF 
recently, isn't it time? 

Since this article was last published in the Sep¬ 
tember/October issue of ;login: there have been 
several additions and changes to the available 
GNU software and the media FSF distributes it 
on. The major ones are detailed in the following 
paragraphs. Almost all of the other older soft¬ 
ware on FSF distribution media has been 
updated to newer versions that are more bug free 
and support more UNIX systems. 

•Several new manuals have been published: 
Using and Porting GNU CC, which explains how 
to run, install, and port the GNU C compiler 
(editions are available for both GCC 1 and GCC 
2); Flex, a lexical scanner generator; GNU Calc, 


an extensible, advanced desk calculator and 
mathematical tool that runs under GNU Emacs. 

•Two new quick reference cards have been pub¬ 
lished: Bison, a parser generator; Flex, a lexical 
scarmer generator. 

•FSF has produced its first CD-ROM, which con¬ 
tains sources to the GNU Project distribution 
and other free software. See pages 66 and 67 in 
the last issue of ;login: for full details and an 
order form. 

•FSF is now offering its software on 8mm Exabyte 
cassettes. 

•FSF's Deluxe Distribution Package includes exe¬ 
cutables and source for all of GNU software in a 
choice of formats, as well as a printed copy of 
each of our manuals. 

•The new quarterly Subscription Service pro¬ 
vides four new versions of the tape of your 
choice for the price of three. It is offered only for 
tapes that change frequently. 

•FSF is now distributing diskettes with some of 
the software that has been ported to MS-DOS: 
Demacs, a port of GNU Emacs, in two versions 
(one which handles 8-bit character sets, and 
one, based on Nemacs, which handles 16-bit 
character sets, including Kanji); DJGPP, a com¬ 
plete port of GCC, libraries, development utili¬ 
ties, and a symbolic debugger, for Intel 80386 
and 80486; Selected Utilities which include: 
Bison, RCS, flex, GAWK, cpi, diff, MicroEmacs, find, 
some file utilities, gdbm, grep, libc, ptx, indent, 
less, m4, make, sed, shar, sort, and Texinfo; and Pro¬ 
grams for Windows, GNU Chess and gnuplot. 

•The gzip utility is the GNU replacement for com¬ 
press and is on all media that contain gziped 
files. It is currently in beta release, gzip com¬ 
presses much more than compress does; a file 
compressed with gzip is usually two thirds the 
size of a file compressed with compress. Addi¬ 
tionally, although gzip is slower than compress, 
gunzip is faster than uncompress. 
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•New software on the Emacs Tape includes: 
CUSP, a Common Lisp interpreter and compiler; 
PCI, a large subset of CLOS, the Common Lisp 
Object System. 

•New Software on the Languages Tape includes: 
GDB 4, the GNU source-level C and C++ debug¬ 
ger. GDB 4 is out of beta test and has moved 
from the Experimental Tape. 

•New Software on the Utilities Tape includes: 
autoconf, produces shell scripts which automat¬ 
ically configure source code packages;/ ax, 
Group 3 fax transmission and reception services 
for a networked UNIX system; mtools, programs 
to allow UNIX systems to read, write, and 
manipulate files on an MS-DOS file system; 
recode, converts files between character sets and 
usages; wdiff, compares two files, finding which 
words have been deleted or added to change 
one into the other; screen, allows several inde¬ 
pendent scr^^ns (ttys) on a single physical termi¬ 
nal; termcapr an improved drop-in replacement 
for libtermcap.a. 

•New software on the Experimental Tape 
includes: Binutils 2.0, this release uses BED 
(Binary File Descriptor) library; Oleo, a spread¬ 
sheet that is better for you than the more expen¬ 
sive spreads. A runtime system for the 
Objective C language is now available. As of 
version 2.3, GCC can run Objective C programs 
on any of the supported target machines. 

•And finally, FSF is now offering GNU T-shirts. 
They are 100% cotton and are available in two 
colors with a picture of an intensely hacking 
gnu on the front. 

Many of the programs in the GNU Software dis¬ 
tribution are covered by either the GNU General 
Public License or the GNU General Library Public 
License. These Licenses permit everyone to have 
and run copies of the programs, at no charge, and 
to redistribute copies under certain conditions 
designed to make sure that all modified versions 
remain as free as the versions GNU distributes. 
The Licenses are usually in files named COPYING 
and COPYING.LIB. They can also be obtained from 
<gnu@prep>. 

[The USENIX Association is printing this information 
as a service to the user community; no endorsement of 
GNU software is implied.] 
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Mobile & Location-Independent Computing 


Mobile & Location-Independent Computing 
Symposium; Preliminary Program 
Cambridge, Massachusetts 
August 2-3,1993 

Like transistors replacing tubes, OSs being writ¬ 
ten in HLLs, high-speed local networking, or dis¬ 
tributed computing, achieving the mobile or 
location-independent computer will profoundly 
change the manner in which we compute. The 
introduction of the light-weight mobile computer 
with plenty of main and virtual memory, mega¬ 
pixel display, backing store, and communications 
hardware is a seminal advancement in tech¬ 
nology. 

It is this conclusion, reached by a number of folks 
independently and collectively within the 
USENIX community, which led to the organiza¬ 
tion of the USENIX Mobile and Location-Indepen¬ 
dent Computing Symposium. The purpose of this 
Symposium is to explore the questions and chal¬ 
lenges that we, as developers and researchers, 
must answer at the dawn of mobile computing. 
We encourage your participation in examining 
the implications of this soon to be pervasive tech¬ 
nology. 

How will mobile computing actually be imple¬ 
mented? What, for instance, happens to filesys¬ 
tems? How do we achieve ''automagic" 
reconciliation of changed data files, possibly of 
changed system configurations, after a mobile 
system has been operating (as the buzzword 
goes) "detached" and is reattached to a network? 

What do we need to change and what is essential 
in the structures and operations of our systems? 
For instance, is Kerberos "good enough" or do we 
need new, different security models? What must 
happen to UNIX to meet the new way of comput- 
ing? 

At this Symposium we hope to accomplish a first 
discussion of the issues. Possible approaches and 
actual experiences will be shared. Two keynote 
addresses from knowledgeable watchers of new 
technology, refereed paper presentations, panel 
discussions, Work-in-Progress Reports, technol¬ 
ogy demonstrations, and Birds-of-a-Feather Ses¬ 
sions will facilitate this discussion. A panel 
discussing what we have learned and where we 
need to go will conclude the Symposium. 


Monday, August 2 

Keynote Address by Bob Metcalfe, Info World 

Dr. Bob Metcalfe is currently Publisher/CEO of 
the Info World Publishing Company. He gradu¬ 
ated from MIT, received his Ph.D. in CS from Har¬ 
vard in 1973, and was a professor at Stanford 
University. In 1988 he received the Alexander 
Graham Bell Medal for his contributions to the 
invention, standardization and commercializa¬ 
tion of local-area networks. He also invented 
Ethernet at Xerox Palo Alto Research Center in 
1973 and founded 3Com Corp. in 1979. 

Connectivity 

The Qualcomm CDMA Digital Cellular System 
Phil Karn, Qualcomm, Inc. 

An Infrared Network for Mobile Computers 
Norman Adams, Bill N. Schilit, Rich Gold, Michael 
Tso, Roy Want, Xerox PARC 

UNIX For Nomads: Making UNIX Support Mobile 
Computing 

Michael Bender, Alexander Davidson, Clark Dong, 
Steven Drach, Anthony Glenning, Karl Jacobs, Jack 
Jia, James Kempf, Nachiappan Periakaruppan, Gale 
Snow, Rebecca Wong, Nomadic Systems Group, 
Sun Microsystems 

Protocols And Messaging 

Providing Connection-Oriented Network 
Services to Mobile Hosts 
Kimberly Keeton, Bruce Mah, Srinivasan Seshan, 
Randy Katz, Domenico Ferrari, University of Cali¬ 
fornia - Berkeley 

A Mobile Networking System Based on Internet 
Protocol (IP) 

Pravin Bhagwat, University of Maryland; Charles 
Perkins, IBM T.J. Watson Research Center 

Agent-Mediated Message Passing for Con¬ 
strained Environments, Andrew Athan, Daniel 
Duchamp, Columbia University 

Panel Discussion 

Active Badges, Civil Liberties, Security, and 

Privacy 

Panelists TBA 
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Technology Demos 

A special feature of the Symposium will be dem¬ 
onstrations of some of the latest products and 
still-in-development technology. Six to eight 
demonstrations will be provided by vendors and 
by researchers, who will then be available to 
answer your questions. 

If you are interested in demonstrating relevant 
technology, please contact Cynthia Deno, 
USENIX Consultant, (408) 335-9445 or email 
< cynthia@usenix.org>. 

Tuesday, Augusts 

Work-in-Progress Reports -TBA 

Filesystems And Naming 

Disconnected Operation for AFS 

Larry B. Huston, Peter Honeyman, University of 

Michigan 

File Access in Mobile Computing Environments 
M. Satyanarayanan et. al., Carnegie Mellon Uni¬ 
versity 

Using Prospero to Support Integrated Location 
Independent Computing 
B. Clifford Neuman, Steven Seger Augart, Shantap- 
rasad Upasani, University of Southern California 

Hosted Luncheon With Keynote Speaker - TBA 

Experience 

BNU: Experiences from an Operating Systems 
Course Project in Mobile Ubiquitous Computing 
Terri Watson, Brian Bershad, Carnegie Mellon Uni¬ 
versity 

Experiences with X in a Mobile Environment 
Christopher A. Kantarjiev, Xerox PARC 

Customizing Mobile Applications 

Bill N. Schilit, Marvin M. Theimer, Brent B. Welch, 

Xerox PARC 

Panel Discussion 

Reprise: Do we need to start over, or are we on the 
right track? 

Panelists TBA 


Program Committee 

Dan Geer, Program Chair 
Geer Zolot Associates 
Clement Cole, Vice-Program Chair 
Locus Computing Corporation 
Ed Gould, Digital Equipment Corporation 
Mike Kazar, Transarc Corporation 
Jeff Kellem, Beyond Dreams 
Alan Nemeth, Digital Equipment Corporation 
Tom Page, UCLA 

Charlie Perkins, IBM TJ. Watson Research Center 
Dave Presotto, AT&T Bell Laboratories 
Jim Rees, University of Michigan 

A limited number of student scholarships are 
available for full-time students. For further Sym¬ 
posium, registration and scholarship informa¬ 
tion, please contact the USENIX Conference Of¬ 
fice. 
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♦ USENIX SUMMER 1993 TECHNICAL CONFERENCE ♦ 

JUNE 21^5,1993 ♦ aNONNATI CONVENTION CENTER ♦ aNONNATI, OHIO 


FOR COMPLETE CONFERENCE 
INFORMATION AND TO REGISTER: 

Please contact: 

USENIX Conference Office 

22672 Lambert St., Suite 613 
Lake Forest, CA USA 92630 
Telephone: +1 (714) 588-8649 
FAX:+1 (714) 588-9706 
E-mail: conference@usenix.org 


CONFERENCE SCHEDULE 


♦ Pre-Registration Savings Deadline 

Tuesday, June 1, 1993 PRE-REGISTER TO SAVE $100 

♦ Hotel Discount Reservation Schedule 

Friday, May 28, 1993 

4 Vendor Displays 

Wed. & Thurs., June 23-24, Noon-6 pm 

4 Birds-of-a-Feather Sessions 

Tues.-Thurs. evenings, June 22-24 

♦ USENIX Conference Reception 

Thurs., June 24, 6-8 pm 

♦ On-Site Conference Registration 

June 20, 4-9 pm, June 21-24, 7:30 am-6 pm 


TUTORIAL PROGRAM 


Monday and Tuesday, June 21-22, 1993 

THE USENIX Association's well-respected tutorial program 
offers you intensive and practical tutorials in essential areas 
of UNIX-related technology. Tutorials are taught by experi¬ 
enced instructors, experts in their field. 

♦ How Networks Work NEW! 

♦ OSF'S Distributed Computing Environment (DCE) 

♦ The Kerberos Approach to Network Security 

♦ Essential UNIX Programming 

♦ Process & Virtual Memory Systems and MP Support NEW! 

♦ Threads, POSIX PThreads & OSF/DCE Threads UPDATED! 

♦ UNIX Power Tools: Getting the Most out of UNIX NEW! 

♦ Security & The X Window System NEW! 

♦ Topics in System Admin - Part 1 NEW! 

♦ Managing the Domain Name System 

♦ Topics in System Admin - Part 2 NEW! 

♦ Symmetric Multiprocessing and Caching 

♦ DCE Remote Procedure Call System NEW! 

4 Sendmail: Inside and Out NEW! 

♦ UNIX Network Programming 

♦ SRV4.2 Internals: File Systems, I/O & STREAMS NEW! 

♦ Windows NT Architecture NEW! 

♦ Achieving Security in an Internet Environment NEW! 

♦ Tcl & Tk: A New Approach to X11 & GUI Programming 

♦ Installing, Configuring & Administering X Systems NEW! 


TECHNICAL SESSIONS PROGRAM 


Wednesday, Thursday, and Friday, June 23-25,1993 

Parallel tracks of presentations of refereed papers, published 
in Conference Proceedings, and talks by invited experts. 

KEYNOTE: 

Evolving New User Interface Technologies for UNIX 

Bruce Tognazzini, SunSoft, Inc. 

♦ Call Path Profiling of Monotonic Program Resources in 
UNIX 

4 Computer System Performance Problem Detection Using 
Time Series Models 

4 Design and Implementation of a Simulation Library Using 
Lightweight Processes 

4 Invited Talk: Five Years of Gateways and Hackers 
4 The Restore-o-Mounter: The File Motel Revisited 
4 The Autofs Automounter 

4 Discovery and Hot Replacement of Replicated Read-Only 
File Systems 

4 Invited Talk: That's Easy with my Editor 
4 X Through the Firewall, and Other Application Relays 
4 The Ferret Document Browser 
4 LADDIS: The Next Generation in NFS File Server 
Benchmarking 

4 Design and Implementation of a Multimedia Protocol 
Suite in a BSD UNIX Kernel 
4 Invited Talk: Introduction to Object-Oriented 
Programming and C++ 

4 Invited Talk: Ten Problems in UNIX, and How Object 
Technology Solves Them 
4 The Spring Nucleus: A Microkernel for Objects 
4 "Stacking" Vnodes: A Progress Report 
4 Anonymous RPC: Low-Latency Protection in a 64-Bit 
Address Space 

4 Invited Talk: Digital Signal Processing 101: 

Sound Programming for your Workstation 
4 Integrating Handwriting Recognition into UNIX 
4 Optimizing UNIX Resource Scheduling for User 
Interaction 

4 AudioFile: A Network-Transparent Audio Server 
4 Invited Talk: Highlights from the 1992 USENIX UNIX 
Security Symposium 
4 Work-In-Progress Reports 
4 Invited Talk: Highlights from the 1993 USENIX 
Mach Symposium 

4 Fast and Flexible Shared Libraries 
4 High Performance Dynamic Linking Through Caching 
4 The Shell as a Service 
4 Invited Talk: Analysing Backup Systems 
4 A User-Level Replicated File System 
4 sfs: A Parallel File System for the CM-5 
4 Adaptive Block Rearrangement Under UNIX 
4 Invited Talk: UNIX Documentation: Where are We and 
How Did We Get Here? 

4 Panel on Privacy 



THE UNIX AND ADVANCED COMPUTING SYSTEMS 
PROFESSIONAL AND TECHNICAL ASSOCIATION 
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Invitation to Students 


A Special Invitation to Full-time Students 

The USENIX Association is making a special invi¬ 
tation to full-time students the USENIX Summer 
1993 Technical Conference from June 21- 25,1993 
at the Cincinnati Convention Center in Cincin¬ 
nati, Ohio. 

AHEND THE KEYNOTE FOR FREE 

Wednesday, June 23, 9:00 am - 

Evolving New User Interface Technologies for 
UNIX, Bruce Tognazzini, SunSoft, Inc. 

Our keynote speaker, Bruce Tognazzini, has long 
been a customer of the operating system support 
for the user interface. He has been designing 
human interfaces for better than 30 years. He 
spent the last 14 years at Apple where he led at 
various times both the Apple II and Macintosh 
human interface efforts before moving to SunSoft 
last year. During his most recent tenure in the 
Evangelism group at Apple, he wrote a major 
new publication in the field of human-computer 
interaction, "Tog on Interface." 

AHEND THE VENDOR DISPLAYS FOR FREE 

Wednesday and Thursday, June 23-24 
Noon - 6:00 pm 

At the USENIX Vendor Display in Cincinnati, ven¬ 
dors will demonstrate advanced computing and 
networking products and services. Here, in a 
relaxed environment, you can get real answers 
from technically-savvy vendor representatives. 
Go ahead, kick the tires, and be sure what's on 
display really does what it's said to do. 

AHEND A TUTORIAL FOR $50 

Monday and Tuesday, June 21-22 
9:00 am-5:00 pm 

A limited number of spaces in each tutorial are 
reserved for full-time students at the special fee of 
$50.00 per tutorial. Telephone the USENIX Confer¬ 
ence Office, +1 714/588-8649 during office hours 
of 8:30 am-5:00 pm. Pacific Time, Monday-Friday 
to confirm availability of the tutorial of your 
choice and to make a reservation. All tutorials 
offer printed materials. Tutorial fee includes a box 
lunch. 

AHEND THE TECHNICAL SESSIONS FOR $75 

Wednesday through Friday, June 23-25 
Sessions begin at 9:00 am 


A program of parallel tracks of presentations of 
refereed papers and tutorial-style talks by invited 
experts is rounded out by Work-in-Progress 
Reports (students: schedule your WIP report by 
sending email to <WIP@usenix.org>), a panel dis¬ 
cussion on privacy, and highlights from recent 
USENIX single-topic symposia. The conference 
reception is included in the fee. Also included is a 
copy of the Conference Proceedings and a copy of 
the Invited Talks Submitted Notes. 

USENIX SUPPORTS STUDENT PARTICIPATION AND 
PROFESSIONAL DEVELOPMENT 

•The USENIX Educational Outreach Program 
provides full-time students access to full confer¬ 
ence scholarships and USENIX publications. 

•A $500 cash prize is awarded for the Best Stu¬ 
dent Paper at USENIX annual Winter and Sum¬ 
mer Conferences. (Students are eligible also for 
Best Paper and other awards.) 

Membership in USENIX for full-time Students is 
only $20. As a member, your benefits include: 

•Free subscription to ;login:, bimonthly newslet¬ 
ter with articles, community news, calendar of 
events, book reviews. Standards Activities 
Reports, Systems Administrators' Guild News, 
and more 

•Free subscription to Computing Systems, refereed 
technical quarterly published with the Univer¬ 
sity of California Press 

• $75 technical sessions fees vs fees of $275 to $340 
for as many as ten technical conferences and 
symposia each year and $50 tutorials at USENIX 
annual Winter, Summer and Systems Adminis¬ 
tration Conferences 

•Discounts on conference/symposia proceed¬ 
ings, other technical publications, and books 
from the new series on advanced computing 
published with MIT Press 

•Eligibility to join SAGE, the Systems Adminis¬ 
trators' Guild 

And maybe most important, participation in 
leadership in the UNIX community. 
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USENIX 

UNIX 

Security 

Symposium 

OCTOBER 4-7,1993 
SANTA CLARA 
MARRIOTT HOTEL 
SANTA CLARA, 
CALIFORNIA 


Important Dates 


Dates for Refereed Paper 
Submissions: 

^ Extended abstracts due: 

June 4,1993 

^ Program Committee decisions 
made: June 30,1993 
^ Camera-ready final papers due: 
August 15,1993 

Registration Materials Available: 

^ July, 1993 



ANNOUNCEMENT/CALL FOR PAPERS 


Sponsored by the USENIX Association 

^ Co-Sponsored with The Computer Emergency Response Team (CERT) 

^ In cooperation with The ACM SIGSAC 

The goal of this symposium is to bring together security practitioners, 
system administrators, system programmers, and others with an interest in 
computer security as it relates to networks and the UNIX operating system. 

This will be a three and one-half day, single-track symposium. The sympo¬ 
sium will consist of tutorials, refereed and invited technical presentations, 
and panel sessions. The first day will be devoted to tutorial presentations. 

The following two-and-one-half days of technical sessions will begin with 
the keynote address by Robert H. Morris. There will also be two evenings 
available for Birds-of-a-Feather sessions and Works-in-Progress sessions. 

Tutorials 

October 4,1993 

This one-day tutorial program wiQ feature two tutorials, designed to ad¬ 
dress the needs of both management and technical attendees. The tutorials 
will supply overviews of various security mechanisms and policies. Each 
will provide specifics to the system and site administrator for implementing 
numerous local and network security precautions, firewalls, and monitoring 
systems. 

Keynote and Technical Sessions 

October 5-7,1993 

The keynote address by Robert H. Morris, Sr. of NCSC will begin the 
technical sessions program. Mr. Morris will speak on information security 
in computing. He wiQ cover a number of subjects that bear directly on secu¬ 
rity. Principal among these will be the shoddy quality of software. In short, 
he considers the question "if the program is full of bugs, what can you say 
about its security?" 

The technical sessions program will include refereed paper presentations, 
invited talks, and panel sessions. The program committee invites you to 
submit proposals, ideas, or suggestions for these presentations. Papers that 
have been formally reviewed and accepted will be presented during the 
symposium and published in the symposium proceedings. Proceedings 
will be distributed free to technical session attendees during the symposium 
and after will be available for purchase from the USENIX Association. 

Symposium Topics 

Papers are being solicited in areas including but not Unuted to: 

^ User/system authentication 
^ File system security 
^ Network security 
^ Security and system management 

^ Security-enhanced versions of the UNIX operating system 
^ Security tools 

^ Network intrusions (including case studies and intrusion detection 
efforts) 

^ Security on high-bandwidth networks 

(continued on reverse side) 


May/June 1993 


;login: 45 
































^ Program Qiair 

Bill Qieswick, 

AT&T Bell Laboratories 

Steve Bellovin, AT&T Bell 
Laboratories 

Matt Bishop, Dartmouth College 
Ed DeHart, CERT, Carnegie 
Mellon University 
Jim Ellis,CERT, Carnegie Mellon 
University 

Marcus Ranum, Trusted 
Information Systems 



Dates for Refereed Paper Submissions 

^ Extended abstracts due: Jime4,1993 
^ Program Committee decisions made: June 30,1993 
^ Camera-ready final papers due: August 15,1993 

To Send Submissions 

^ Send ASCII or Postscript submissions to: ches@research.att.com 
^ Send hard copy submissions to the program chair: 

Bill Cheswick 
AT&T Bell Laboratories 
Room 2c416 
600 Moimtain Ave. 

Murray Hill, NJ 07974 

For Registration Information 

Materials containing all details of the symposium program, symposium 
registration fees and forms, and hotel discount and reservation information 
will be mailed beginning July 1993. If you wish to receive the registration 
materials, please contact: 

^ USENIX Conference Office 
22672 Lambert Street, Suite 613 
Lake Eorest, CA USA 92630 
+1 (714) 588-8649; FAX: +1 (714) 588-9706 
E-mail: conference@usenix.org 



USENIX, the UNIX and Advanced Computing Systems 
Professional and Technical Association. 
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ANNOUNCEMENT/CALL FOR PARTICIPATION 



U S E N I X 
Systems 
Adminisration 
Conference 

(LISA VII) 

NOVEMBER 1-5,1993 
MARRIOTT HOTEL 
MONTEREY, 
CALIFORNIA 


Important Dates 


Dates for Refereed Paper Submission 
^ Extended Abstract Submission: 

Deadline; July 2,1993 
^ Notification to Authors: 

July 23,1993 

^ Final Papers Receipt Deadline: 
September 1 ,1993 

Registration Materials Available: 

^ August, 1993 



The annual USENIX Systems Administration Conference provides a forum in which 
system administrators meet to share ideas and experiences. A growing success for 
the past six years, the USENIX Systems Admmistration Conference is the only confer¬ 
ence which focuses specifically on the needs of system administrators. Its scope 
includes system administrators from sites of aU sizes and configurations. 

Tutorial Program 

Monday and Tuesday, November 1-2,1993 

The two-day tutorial program at the conference is divided into three tracks with a 
total of twelve half-day tutorials. Attendees may move between tracks, choosing 
which sections most interest them. Tutorials offer expert instruction in areas of inter¬ 
est to system administrators, novice through experienced. Topics are expected to 
include Networking, Programming in Perl, X and the Administrator, the Domain 
Name System, Sendmail, and more. 

Technical Sessions 

Wednesday through Friday, November 3-5,1993 

"The Human Aspect of UNIX System Administration" is the theme of the first track 
of the conference technical sessions. Although papers of a more traditional technical 
content are also very welcome, the committee is especially seeking papers on areas 
such as creating policies and procedures, interacting with management and/or users, 
or which describe and evaluate methods aimed at improved communication with 
users and/or management. We are interested in papers which provide freely avail¬ 
able or fully described solutions to existing problems. 

The second track of the conference technical sessions wiU be split between presenta¬ 
tions on very large installation system administration and presentations of practical, 
experience-derived material of special interest to new system administrators. 

No simple measure defines "large installation." It could be number of hosts, number 
of users, size of network, amount of on-line storage, or some combination of these. 

The only certainty is that today's large will be tomorrow's standard. We wish to hear 
from sites which have unique problems and solutions relating to the management of 
large installations. We seek proposals for papers, panels, mini-workshops, or similar 
presentations for this track. 

We also seek papers, mini-workshops, or panel presentations of pragmatic material 
from experienced system administrators who wish to share their experiences, hard¬ 
ships and solutions. It is hoped that administrators at all levels can leverage this 
track to solve specific problems at their site. 

Vendor Display 

Wednesday, November 3,1993,3:00 pm-9:00 pm 

WeU informed vendor representatives will demonstrate products and services useful 
to systems and network administration at the informal table-top display accompany¬ 
ing the USENIX Systems Administration Conference. 

If your company would like to participate, please contact Cynthia Deno at 
+1 (408) 335-9445, FAX +1 (408) 335-2163, E-mail: cynthia@usenix.org 

Conference Topics 

The technical sessions program wiU include invited talks, panels, Works-In-Progress 
(WIP) reports, and Birds-Of-a-Feather (BOF) sessions, alongside the refereed paper 
presentations. The program committee invites you to submit informal proposals, 
ideas, or suggestions, for the various presentation formats, on any of the following or 
related topics: 

^ Implementation, usage, and strategies for Policies and Procedures 
^ Effects of improved communication with users and/or management. 

^ Tricks in user education 
^ How to develop Junior System Administrators 

(continued ou reverse side) 


































^ Program Chain 

Bjorn S^Lideva,/sys/admin, Inc. 

Brent Chapman, Great Circle 
Associates 

Lee Damon, Castle PALIS 

Tina M. Darmohray, Lazvrence 
Livermore National Labs 

Janet Frazer, UNIX System 
Laboratories, Inc. 

Helen Harrison, SAS Institute 
Dinah McNutt, Tivoli Systems 
Bryan McDonald, SRI International 
Arch Mott, Cisco Systems, Inc. 

Paul Moriarty, Cisco Systems, Inc. 

Jeff Polk, Berkeley Software Design, Inc. 

Greg Rose, Australian Computing and 
Connnunications Institute 

Peg Schafer, Bolt Beranek & Neioman, 
Inc. 

Steve Simmons, Industrial Technology 
Institute 

Liza Y. Weissler, RAND Corporation 
Pat Wilson, Dartmouth College 
Elizabeth Zwicky, SRI International 



^ System Security Monitoring 

^ Security issues, especially where multiple people are privileged users 
^ Heterogeneous system administration 
^ Human issues of administration 
^ Graphical User Interfaces for system administration 
^ Distributed system administration 
^ Network growth and performance management 
^ Network management 
^ Network monitoring 
^ Wireless LANs 

^ Evaluating performance of high-end workstations and servers 
^ Integration of heterogeneous systems 
^ Usage monitoring and accounting systems 
^ Administration of remote sites 

Refereed Paper Submissions 

The committee requires that an extended abstract be submitted for the paper selection 
process. (Full-papers are not acceptable for this stage; if you send a full paper, you 
must also include an extended abstract for evaluation.) Your extended abstract 
should consist of a traditional abstract which summarizes the content/ideas of the 
entire paper, followed by a skeletal outline of the full paper. We require electronic 
(nroff/troff, TeX or ASCII) submission of the extended abstract. 

Authors of an accepted paper will present their paper and provide a final paper for 
publication in the Conference Proceedings. Final papers are limited to 20 pages, 
including diagrams, figures and appendix. Papers should include a brief description 
of the site (if applicable), an outline of the problem and issues, and details of the solu¬ 
tion. Authors may provide electronic versions or camera-ready copy (instructions 
will be provided upon request) of final papers. Conference proceedings will be dis¬ 
tributed to all conference attendees and will also be available from the USENIX 
Association after the conference. 

Address For Submission 

For submission of all proposals and of extended abstracts of refereed papers, and for 
program information, contact: 

^ Program Chair: Bjorn Satdeva 
/sys/admin, Inc. 

2787 Moorpark Avenue 
San Jose, CA 95128 
+1 (408) 241-3111 
E-mail: bjom@sysadmin.com 

For Registration Inforaaation 

Materials containing all details of the symposium program, symposium registration 
fees and forms, and hotel discount and reservation information wiU be mailed and 
posted to the net beginning August 1993. If you wish to receive registration materi¬ 
als, please contact: 

^ USENIX Conference Office 
22672 Lambert Street, Suite 613 
Lake Forest, CA 92630 USA 
+1 (714) 588-8649 
FAX: +1 (714) 588-9706 
E-mail; conference@usenix.org 


USENIX, the UNIX and Advanced Computing Systems 
Professional and Technical Association. 
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HOW TO SUBMIT A REFEREED PAPER 

As at all USENIX conferences, papers that analyze problem areas and draw important 
conclusions from practical experience are welcome. Note that the USENIX conference, 
like most conferences and journals, considers it unethical to submit the same paper 
simultaneously to more than one conference or publication or to submit a paper that has 
been or will be published elsewhere. 

Authors of papers to be presented during the conference technical sessions and published 
in the Proceedings must submit an extended abstract to the Program Committee by July 
13, 1993. The object of an extended abstract is to convince the reviewers that a good 
paper and 25-minute presentation will result. They need to know that authors: 

^ are attacking a significant problem; 

^ are familiar with the current literature about the problem; 

^ have devised an original solution; 

^ have implemented it and, if appropriate, characterized its performance; 

^ have drawn appropriate conclusions about what they have learned and why it is 
important. 

An extended abstract should be about 5 pages in length, or about 2500 words. It should 
represent the paper in “short form.” Please include the abstract as it will appear in the 
final paper. The body of the extended abstract should be complete paragraphs, not just 
an outline of the paper. (Sections present in the full paper but omitted from the abstract 
may be summarized in terse form; this will help reviewers to understand what material 
will be present in the final paper.) Authors should include full references, and, if 
appropriate, performance data to establish that they have a working implementation and 
measurement tools. Figures should be included when available. 

Authors may, at their option, submit a full paper in addition to the extended abstract. 
Since the schedule for reviewing submissions is short, however, most judgements will 
be made based on the extended abstracts. 

Every submission should include one additional page containing: 

^ The name, surface mail address, daytime and evening telephone numbers, e-mail 
address and (if available) fax number of one of the authors, who will act as the 
contact to the program committee; 

An indication of which, if any, of the authors are full-time students; 

^ A list of A/V needs beyond a microphone and an overhead projector. 

Authors of accepted submissions will be notified by August 30, 1993. They will 
promptly receive instructions for preparing camera-ready copy of an 8-12 page final 
paper, which must be received by November 2, 1993. 


WHERE TO SEND SUBMISSIONS 

Please submit one copy of an extended abstract via at least two of the following methods: 
^ (Preferred method) e-mail to: SF94papers@usenix.org 
^ FAX to: the USENIX Association +1 (510) 548-5738 
^ Mail to: USENIX Winter 94, USENIX Association, 2560 Ninth St., Suite 215, 
Berkeley, CA USA 94710 

Inquiries about submissions to the USENIX Winter 1994 Conference may be made by 
e-mail to SF94info@usenix.org or by telephone to +1 (510) 528-8649. Potential authors 
of technical papers are strongly encouraged to send us electronic mail. This will allow 
us to notify you of any important changes and you will receive additional information 
about the submission and reviewing process. You may request a sample extended 
abstract by telephoning +1 (510) 528-8649, by fax to +1 (510) 548-5738, or by e-mail 
to sample-abstract@usenix.org 


<^CALL 

FOR 

PAPERS 


USENIX WINTER 
1994 TECHNICAL 
CONFERENCE 



JAN.17-21,1994 
SAN FRANCISCO 
CALIFORNIA 


DATES FOR 
REFEREED 
PAPER 
SUBMISSIONS 

EXTENDED ABSTKACTS DUE: 

JULY 13, 1993 

NOTIFICATION TO AUTHORS: 

AUGUST 30, 1993 

CAMERA-READY PAPERS DUE: 

NOVEMBER 2, 1993 


CASH PRIZES 

CASH PRIZES WIU. BE 
AWARDED BY THE PROGRAM 
COMMITTEE FOR BEST PAPER, 
BEST PRESENTATION, AND 
BEST STUDENT PAPER. 










USENIX WINTER 
1994 TECHNICAL 
CONFERENCE 



JAN.17-21,1994 
SAN FRANCISCO 
CALIFORNIA 


For many years, UNIX and its derivatives have been the only 
widely available “open” operating systems to support modem 
software technology. The next few years promise to change that, 
as many new PC operating systems are reaching the market. 
These systems will compete with UNIX, but they will also 
broaden the set of systems that can support advanced applications, 
high-performance computing, novel user interfaces, 
and improved network communication. The question is not 
“will UNIX survive,” but rather how will UNIX and other systems 
evolve together to improve our computing environments. 

As usual at USENIX Conferences, we are interested in papers 
describing new and interesting developments in open operating 
systems. Our traditional focus on UNIX remains, but this includes 
lessons learned from work on UNIX that can be applied more 
broadly, and lessons from other kinds of systems that can be 
applied to the continuing evolution of UNIX. 


CONFERENCE SCHEDULE IN BRIEF 

Unusual for a USENIX Conference, at San Francisco, the 3 days of 
technical sessions preeede the 2-day tutorial program. 

Other conference events are scheduled accordingly. 

TECHNICAL SESSIONS: 

MONDAY THROUGH WEDNESDAY JANUARY 17-19, 1994 

TUTORIALS: 

THURSDAY AND FRIDAY, JANUARY 20-21, 1994 

BIRDS-OF-A-FEATHER SESSIONS: 

MONDAY THROUGH THURSDAY EVENINGS, JANUARY 17-20, 1994 

USENIX RECEPTION: 

TUESDAY EVENING, JANUARY 18, 1994 

VENDOR DEMONSTRATIONS: 

TUESDAY AND WEDNESDAY, JANUARY 18-19, 1994 


VENDOR DEMONSTRATIONS 

At San Francisco, vendors will offer short talks and demonstrations of a product or 
service in a theater-style setting. Technical representatives then will answer specific 
questions from conference attendees. In addition to scheduled demonstrations, there will 
be a display area especially for publications and software/communications products and 
services. Vendors, to participate please contact: Cynthia Deno +1 (408) 335-9445, FAX: 
+ 1 (408) 335-2163, E-mail: cynthia@usenix.org 











TUTORIAL PROGRAM 


On Thursday and Friday of the Winter 1994 Conference, you can explore topics essential 
to successful use and development of UNIX and UNIX-like operating systems, X 
windows, networking and interoperability, advanced programming languages, and 
related areas of interest. The USENIX Association’s well-respected program offers you 
introductory and advanced, intensive yet practical tutorials. Courses are presented by 
skilled teachers who-are hands-on experts in their topic areas. 

At San Francisco, USENIX will offer two full days of tutorials covering topics such as: 
^ Introductory and advanced systems UNIX power tools 

administration ^ System and network security 

^ Distributed computing: DCE, DME, DFS, ^ Windows NT 

RPC ^ Network program mainte- 

Kernel internals: OSF/1, SVR4,4.4BSD nance and design 

^ Developing and debugging X-based ^ Systems programming and 

applications product development 

^ GUI technologies and builders 

To provide the best possible tutorial slate, USENIX is constantly soliciting proposals for 
new tutorials. If you are interested in presenting a tutorial, contact the Tutorial 
Coordinator: Daniel V. Klein +1 (412) 421-2332, E-mail: dvk@usenix.org 

INVITED TALKS 

The conference technical sessions include one track of 30-minute long presentations of 
papers selected by the Program Committee. A second track of Invited Talks, compli¬ 
ments the first. These talks by invited experts provide introductory and advanced 
information about a variety of interesting topics, such as using standard UNIX tools, 
tackling system administration difficulties, or employing specialized applications. This 
second track also includes selections from the best presentations offered at 1993 
USENIX single-topic Symposia and panel discussions. 

The Invited Talks Coordinators welcome suggestions for topics as well as request 
proposals for particular Talks. In your proposal, state the main focus, include a brief 
outline, and be sure to emphasize why your topic is of general interest to our community. 
Please submit to: Brent Welch, Xerox PARC and Bob Gray, US WEST Advanced 
Technologies via e-mail to ITusenix@usenix.org 


CONFERENCE 

PROGRAM 

COMMITTEE 

PROGRAM CHMR: 

JefiEtey Mogul, 

Digital Equipment Corporation 

Rafoel Alonso, Matsushita Irtformation 
Technology Laboratory 
Brian N. Beishad, CMC/ 
Nathaniel S. Bocenstein, Bellcore 

Frederick S. Glover, Digital Equipment 
Corporation, UNDC^ Software Group 

Judith E. Grass, Corporation for 
National Research Initiatives 

Mchael B. Jones, Microsoft Research, 
Microsoft Corporation 

Ftiil Kam, Qualcomm, Inc, 

Samuel J. Leffler, 

Silicon Graphics, Inc, 

D, R, McAuley, 

University of Cambridge 

David Presotto, 

AT&T Bell Laboratories 

Margo Seltzer, Harvard University 

Cathy L. Watkins, Intel Corporation, 
O/S Technology Engineering 


CONFERENCE 
PROGRAM AND 
REGISTRATION 


BIRDS-OF-A-FE ATHER SESSIONS 

The always popular Birds-of-a-Feather sessions (BOFs) bring together devotees of 
many varied disciplines for demonstrations, discussion, armouncements, and mingling. 
BOFs are offered Monday through Thursday evenings. Schedule a BOF on site or in 
advance by contacting the USENIX Conference Office, +1 (714) 588-8649, E-mail: 
conference @ usenix.org 

WORK-IN-PROGRESS REPORTS 

WIP Reports, scheduled during the conference technical sessions, are designed to 
introduce interesting new or ongoing work. At this conference, we are particularly 
interested in promoting student research. Presentations should be short, pithy and fun! 
The USENIX audience provides valuable discussion and feedback. Schedule your Work 
In Progress (WIP) Report by contacting the WIP Coordinator, Peg Schafer, BBN Inc., 
on-site or in advance via e-mail to wip@usenix.org 


Materials containing all details of the 
technical sessions and tutorial program, 
conference registration, hotel and airline 
discount and reservation information will 
be mailed at the end of September 1993. 



PLAN NOW 
TO ATTEND 



USENIX 

C++ 

Technical 

CONFEREh+:E 

APRIL 11-14,1994 
MARRIOTT HOTEL 
CAMBRIDGE, 
MASSACHUSETTS 


FOR PARTICPATION 


Important Dates 


' Tutorial proposals due: 

October 15,1993 

Extended abstracts of Technical 
Sessions submissions due; 
November 1,1993 

Technical Sessions papers 
acceptance: 

January 15,1994 

Final Technical Sessions papers 
due: 

February 21,1994 
Advanced Workshop 
submissions due: 

February 1,1994 

Advanced Workshop acceptance: 

March 1,1994 

Technical Sessions program and 
registration materials available: 

February, 1994 


The USENIX Association is pleased to host its sixth annual C++ Conference 
in Cambridge, Massachusetts, April 11-14,1994. Monday and Tuesday will 
offer tutorials; technical sessions will take place Wednesday and Thursday. 

A post-conference advanced workshop will be held Friday, April 15. 

Tutorials 

^ Monday and Tuesday, April 11-12,1994 

Two full-day tutorials per day will present intermediate and advanced topics 
of interest to C++ developers. Potential presenters should contact the pro¬ 
gram chair for information on how to propose a tutorial. The last date for 
submission of a tutorial proposal is October 15,1993. Tutorial proposals wiQ 
be reviewed and accepted on an on-going basis as they are received by the 
Committee. 

All others are invited to contact the chair to suggest tutorials on topics they 
wish to see covered. 

Technical Sessions 

^ Wednesday and Thursday, April 13-14,1994 

The two days of technical sessions will cover the spectrum of recent research, 
development, and experience in C++. The technical sessions will begin with a 
keynote address and feature presentations of refereed papers. Controversial 
topics may be addressed in an alternative format, such as a panel session. 
Time on Wednesday and Thursday evenings is reserved for Birds-of-a- 
Feather Sessions. (You may schedule a BOF on-site or in advance by email to 
conference@userdx.org) AJl papers accepted by the Program Committee wiU 
be published in the Conference Proceedings, which wiU be distributed to confer¬ 
ence attendees. After the conference. Proceedings wiU be available for purchase 
from the USENIX Association. 

Papers are solicited by the Program Committee on all aspects of C++, 
including; 

Design methods, patterns, and architectures 
Development environments and tools 
Class libraries, frameworks, and generators 
Compilation and run-time support 
Distributed and parallel systems 
Teaching and learning C++ 

Databases and persistence 

Integration with other languages, databases, tools, and methods 
Application development 

Vendor Display 

^ Wednesday, April 13,1994 Noon-6:00 pm 

Well informed vendor representatives wiQ demonstrate products and services 
useful to C++ and the wide range of object-oriented technology at the infor¬ 
mal table-top display accompanying the USENIX C++ Conference. If your 
company would like to participate, please contact Cynthia Deno at +1 (408) 
335-9445, FAX +1 (408) 335-2163, Internet: cynthia@usenix.org 
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^ Program Chair Doug Lea, 

State University of New York 
at Oswego 

Desmond D'Souza, 

Icon Computing 

Erich Gamma, Taligent 

Judith Grass, Corporation for 
National Research Initiatives 
Mark Linton, Silicon Graphics, Inc. 
Scott Meyers, Braivn University 
Vince Russo, Purdue University 
Michael Tiemann, Cygnus Support 
Steve Vinoski, Hewlett-Packard 

Jim Waldo, Sun MicroSystems 
Laboratories 



How TO Submit to the Technical Sessions 

Extended abstracts of no more than ten pages should be submitted to the 
program chair by November 30,1993. Electronic submissions (PostScript, 
troff, or TeX) are preferred. Otherwise, submit eight paper copies. All sub¬ 
missions should indicate the electronic mail address and/or telephone 
number of a principal contact. Authors will be notified of acceptance by 
January 15,1994 and will be provided with guidelines for preparing the final 
paper. Authors of an accepted paper will deliver a presentation during the 
conference technical sessions and provide a final paper for publication in the 
Conference Proceedings. Final versions of papers are limited to twenty pages 
and are due by February 21,1994. 

How TO Submit to the Advanced Workshop 

•- Friday, April 15,1994 

The one-day post-conference workshop wiU focus on the development of 
methods, tools, and services supporting the use of C++ in distributed com¬ 
puting. Attendance is limited, and based on acceptance of a position paper. 
Acceptance notices to all participants will be issued by March 1,1994. 

Potential workshop attendees are invited to submit a position paper of at most 
3 pages (ASCII) to the program chair no later than February 1,1994. Position 
papers should briefly describe experiences, interests, works-in-progress, and/ 
or ongoing research and development. (More substantiative reports of com¬ 
pleted work should instead be submitted to the technical sessions.) 

A representative subset of authors of position papers wiQ be invited to make 
informal presentations at the workshop. 

Where to Send Submissions and Address Inquiries 

^ All queries and submissions should be directed to the program chair: 

Doug Lea 

Dept, of Computer Science 
SUNY Oswego 
Oswego NY USA 13126 
Phone: +1 (315) 341-2688 
Internet: dl@g.oswego.edu 

For Program and Registration Information 

Materials containing full details of the conference program, registration fees 
and forms, and hotel discount and reservation information wiQ be mailed and 
posted to the net in February 1994. If you wish to receive registration materi¬ 
als, please contact: 

^ USENIX Conference Office 
22672 Lambert Street, Suite 613 
Lake Forest, CA USA 92630 
Phone: +1 (714) 588-8649; FAX: +1 (714) 588-9706 
Internet: conference@usenix.org 


USENIX, the UNIX and Advanced Computing Systems 
Professional and Technical Association. 
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USENIX 

UNIX 

Applications 

Developmep^ 

Symposium 

APRIL 25-28,1994 
MARRIOTT HOTEL 
TORONTO, 
ONTARIO; CANADA 


Important Dates 


DATES FOR REFEREED PAPER 
SUBMISSIONS: 

^ Extended Abstracts Due: 

January 10,1994 

^ Notifications to Authors: 

January 26,1994 

^ Final Papers Due: 

March 11,1994 

OTHER IMPORTANT DATES: 

^ Pre-Registration Materials available: 
Mid-February, 1994 

^ Tutorial Program: 

Monday & Tuesday, April 25 & 26 

^ Technical Sessions: 

Wednesday & Thursday, 

April 27 & 28 

i*" Birds-Of-a-Feather Sessions: 

Monday-Thursday evenings 

^ USENIX Reception: 

Wednesday evening, April 27 


CALL FOR PARTICIPATION 


Cosponsored by the USENIX Association and 
UniForum Canada 

One of the major uses of UNIX is the support, development, and execution of 
applications which ultimately serve as tools for end-users. In addition, the current 
trend of downsizing major applicatior\s from monolithic data-center enviromnents 
to less expensive, distributed workstations and client-server computing environ¬ 
ments affords UNIX a serious position in the commercial marketplace. Because 
UNIX has become a viable commercial alternative, vendors are now porting and 
developing code for scientific and business applications which in the past have 
been the province of contributed code. Consequently, more and more computing 
and information systems professionals are encountering UNIX when developing 
and maintaining applications. 

The purpose of the UNIX Applications Development Symposium is to expose 
the challenges of building and maintaining applications on UNIX platforms, to 
discuss solutions and experiences, and to explore existing practice and technique. 
Computing professionals who have long viewed UNIX as the program develop¬ 
ment platform of choice, as well as professionals new to the UNIX environment, 
will learn of helpful tools, novel approaches, and what not to do when developing 
for or porting an application to the UNIX environment. 

The symposium will feature technical papers, invited talks, panel discussions, and 
tutorials on all aspects of designing, building, testing, debugging, and maintaining 
applications within and for the UNIX environment. There will be ample opportu¬ 
nity to meet your peers and make contact with others with similar interests. 

The UNIX Applications Development S 5 Tnposium will provide valuable infor¬ 
mation to designers, programmers, and managers who plan to port existing 
applications into the UNIX environment or move development and maintenance 
teams from various proprietary environments to UNIX. 

Tutorial Program 

The two, day-long tutorials are targeted to programmers and managers interested 
in developing applications in, and products for, the UNIX environment. Each is 
led by an experienced instructor who is an expert in his topic. The Monday tuto¬ 
rial by Richard Stevens covers the use of the UNIX environment to develop 
applications. The tutorial on Tuesday, presented by Rob Kolstad, covers design 
and implementation issues regarding effective use by an application of the UNIX 
environment. 

Invited Talks and Panel Sessions 

As part of the technical sessions, invited talks provide introductory and advanced 
information about a variety of interesting topics, such as using standard UNIX 
tools and employing specialized applications. We welcome suggestions for topics, 
as well as request proposals for particular talks. You are encouraged to direct a 
proposal to the program chair. State the main focus, include an outline, and em¬ 
phasize why the topic of the talk is of general interest. 

Panel sessions on technical issues are welcome. Persons interested in participating 
in panel discussions should also contact the program chair. 

Works-In-Progress Reports 

These reports provide researchers, developers, and implementors with ten min¬ 
utes to speak on current work and receive valuable feedback. Present your 
interim results, novel approaches, or newly-completed work. Schedule your re¬ 
port in advance or on-site. Inquiries about WIPs should be directed to the 
program chair. 

Suggested Topics 

^ Graphical User Interfaces - The X Window System. User Interface Design and 
Standards. Open Look, Motif, and NeWS. Style guides and toolkits. Importance 
of consistency and ease of use. 
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Program Committee, 


^ Program Chain 

Jim Ehmcan, Math Depart., 

The Pennsylvania State University 

^ Program Vice-Chain 

Greg Woods, GAW Consulting 

Dan Heller, Z-Code Softzoare, Inc. 

Rob Kolstad, Berkeley Softzuare 
Design, Inc. 

Evan Leibovitch, Sound Software 

Peter Renzland, Ontario Govern¬ 
ment 

Dan Tomlinson, Compusoft 

Elizabeth Zwicky, SRI International 
Inc. 


Dates For Refereed 
Paper Submissions 


Extended Abstracts Due: 

January 10,1994 

Notifications to Authors: 
January 26,1994 
Final Papers Due: 

March 11,1994 


For Program 
AND Registration 
Information 


Materials containing all details 
of the technical and tutorial pro¬ 
grams, conference registration, 
and hotel and airline discounts 
and reservation information will 
be mailed in mid-February 1994. 

If you wish to receive the registra¬ 
tion materials, please contact: 

^ USENIX Conference Office 
22672 Lambert St., Suite 613 
Lake Forest CA USA 92630 
+1 (714) 588-8649 
FAX: +1 (714) 588-9706 
E-mail: conference@usenix.org 



The UNIX and Advanced 
Computing Systems Professional 
and Technical Association. 


^ Porting Issues - Issues surrounding the tasks of porting an existing application 
to UNIX, as well as issues of making UNIX applications portable to other architec¬ 
tures and other platforms. POSIX compliance. 

^ Networking - Clienterver design issues. How and wheje to separate the 
functions of clients and senders. Novel paradigms. The impact of mobile comput¬ 
ing on application design and testing. The impact of network design or selection 
on application development and performance. 

^ CASE and Project Management - Using UNIX tools and environment to sup¬ 
port code development and project management. Notable gains and kisses. 
Modifications and adaptations to well-known techniques. 

^ Operating System Issues - Adapting to limitations or benefits of various hard¬ 
ware platforms and operating systems. POSIX and COSE. 

^ Security - The impact of security features. Schemes for maintaining securiU^ 
within an application. Client/server issues. Encryption schemes. Issues affecting 
hiLegrit}'^ reliability, and non-repudiation. Using Kerbei ns and other Lhird-party 
systems in applications. 

^ Transaction Processing - Implementing distributed transaction processing for 
UNIX applications. Performance and scaling issues. 

^ Distributed Applications - How do you make the best use of existing LfNIX 
functionality to build UNIX applications? Novel solutions. Client/server consid¬ 
erations. 

^ Object Oriented Programming - Productivity, languages, techniques, case 
studies. Experiences using C++, Eiffel, or other languages in code development. 

^ Internetworking - Effects on application design and support, Interesting or 
useful development platforms. Portability issues. Appropriate use. Advantages 
and disadvajitages of vaj-ious network architectures. 

^ Delivering and Installing Applicarions - Best methods. Superuser require¬ 
ments. Licenses and license administration. Software piracy. Preventing worms 
and viruses. How to do updates effectively, economic^ly, and securely. 

Testing and Certification - The impact of compliance. Experiences coding for 
and meeting compliance with various standards. Applications and IO>IX.l Con¬ 
formance Testing. 

^ Application Standards - What are ABI, API, and ANDF? Selection criteria and 
impact on application design and development. 

Submission Details 

Papers may feature real-life experiences, as well as research topics. Both case- 
study and technical papers will be accepted. Case studies should describe existing 
systems and include implementation details; performance data is strongly encour¬ 
aged. 

A submission must be in the form of an extended abstract (1500-2500 words, 

3-5 pages in length). The extended abstract should represent your paper in short 
form. It should demonstrate that you have a real project, that you are familiar 
with the work in your area, and that you can clearly explain yourself. 

Papers will be judged on technical merit, relevance to the theme, and suitability 
for presentation. Software and hardware developers who wisli to share their 
experiences, innovative solutions, and techniques are encouraged to submit 
papers. 

Please submit one copy of an extended abstract (e-mail preferred) via: 

^ E-mail: <app-dev-sub@math.psu.edu> 

FAX: +1 (814) 865-3735 to Jim Duncan re: USENIX App Dev 94 

^ Postal mail: Jim Duncan 

USENIX App Dev 94 
Math Depart., Penn State University 
218 McAllister Building 
University Park PA USA 16802 

Please refer to "USENIX App Dev 94" on all FAXes and postal mail. 

Please direct inquiries regarding the symposium to <jim@math.psu.edu>. 
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NOSSDAV Workshop 


Fourth International Workshop On Network 

And Operating System Support For Digital 

Audio And Video 

November 3-5,1993 

Lancaster House Hotel 

Lancaster, UK 

In cooperation with: 

ACM SIGCOMM, ACM SIGOPS, ACM SIGOIS, IEEE, 
USENIX Association 

Relevant Areas 

Important topics for the workshop include (but 
are not limited to): 

Broadband/ATM networks 
Multimedia network interfaces 
Comms protocols for multimedia 
Microkernel and OS support 
Application of real-time techniques 
Media synchronisation 
Quality of service support 
Multimedia storage and I/O architectures 
Distributed multimedia systems 
Integrative standards, e.g. TINA and ODP 
Performance studies 

Workshop Theme 

Network and operating system support for digi¬ 
tal audio and video is currently an area of intense 
activity, and a number of core techniques are 
beginning to emerge. The emphasis of this work¬ 
shop will be on integration of key technologies to 
produce complete solutions. 

The role of the operating system is seen as partic¬ 
ularly important in this respect. Papers are also 
welcomed on practical experiences of developing 
multimedia systems. 

The workshop is intended to bring together prac¬ 
titioners from a variety of areas, including com¬ 
munications and networks, operating systems, 
real-time systems and distributed computing. It 
is intended that the workshop will produce an 
agreed position statement on the state of the art in 
the field, highlighting major areas requiring 
future research. 

Instructions For Submitting Papers 

Authors are requested to submit to 
<av-workshop@comp.lanes.ac.uk>, a 500-2000 word 


position paper or an extended abstract of a full 
paper (in raw, unformatted text) by electronic 
mail. 

Only if electronic submission is impossible, 
papers may be sent to: 

Prof. W.D. Shepherd 
Computing Department 
Engineering Building 
Lancaster University 
Lancaster LAI 4YR, UK 
Fax: +44 524 381707 
Phone +44 524 59 3827 
Email: <doug@comp.lanes.ac.uk> 

The proceedings of the workshop will be pub¬ 
lished by Springer-Verlag and the best papers 
will be forwarded to selected journals for publica¬ 
tion. 

Important Dates 

Abstracts due: July 19,1993 

Acceptance notification: August 30,1993 

Final paper due: October 4,1993 

Program Committee 

Doug Shepherd, Laneaster University, UK (Chair) 
Gordon Blair, Laneaster University, UK 
Katrin Braun, Siemens, Germany 
Guy Cherry, Tektronix, USA 
S. Christodoulakis, MUSZC, Greeee 
Robert Ensor, AT&T Bell Labs, USA 
Domenico Ferrari, U. of California, Berkeley 
J.J. Garcia-Luna, SRI International, USA 
Riccardo Gusella, HP Labs, USA 
Ralf Herrtwich, IBM ENC, Germany 
Andrew Hopper, Olivetti Research Limited, UK 
Jim Kurose, U.of Massachusetts, USA 
Albert Kuendig, ETH, Zurich, Switzerland 
Tom Little, Boston University, USA 
Derek McAuley, Cambridge University, UK 
Richard Nicol, BT Labs, UK 
Duane Northeutt, Sun Labs, USA 
Steve Pink, SICS, Sweden 
Radu Popescu-Zeletin, GMD FOKUS, Germany 
R Venkat Rangan, U. of California., San Diego 
Jonathan Rosenberg, Bellcore, USA 
Jean-Bernard Stefani, CNET, Paris, France 
Daniel Swinehart, Xerox Parc, USA 
Steve Wright, HP Labs, UK 
Martina Zitterbart, U. of Karlsruhe, Germany 
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SUG Conference 


Call For Papers; Sun User Group 
Eleventh Annual Conference 
December 7-9,1993 
San Jose, California 

Theme: 

The Metamorphosis of SunOS: from class¬ 
room to boardroom 
Suns in the corporate environment 
Migrating from mainframes to Suns 
Conversion to Solaris 2: a global issue 

The Sun User Group is pleased to host its Elev¬ 
enth Annual Conference and Exhibit, which will 
address the use of Suns in education, research, 
and business. Technical papers and presentations 
concerning this topic, as well as other topics of 
interest to the Sun/SPARC community, are 
invited. Manufacturers of computer equipment 
and software based on SPARC/Solaris technology 
are encouraged to participate in this conference 
with presentations, and participation in the con¬ 
ference exhibition. 

SUG conferences are attended by members from 
all over the world. The 1992 conference and 
exhibit was attended by over 4000 people from 24 
countries and 43 states. 

Submission Guideiines: 

Submissions should be in the form of extended 
abstracts (750 to 1000 words) and be sufficiently 
complete to allow the committee to understand 
and evaluate the submission. Abstracts should 
include: 

1. Author name(s), postal and email address(es), 
and telephone number(s) 

2. Presenter name(s), postal and email 
address(es), and telephone number(s) 

3. Title of the paper 

4. Time needed for presentation/questions (30, 
45, 60, 90 min. spots) 

5. Audio-visual requirements 

6. Student paper entry (full-time students only) 


Authors whose submissions are accepted will 
receive instructions for the preparation of final 
papers which will be published in the conference 
proceedings. The Presenter will receive one free 
registration for the conference. Registration for 
any tutorial must be purchased. 

Importantl All presentations will require a paper 
submission for inclusion in the conference pro¬ 
ceedings. 

Submit one hardcopy and one electronic copy to 
the program chair: 

Peter Galvin 

Systems Manager 

Brown University 

Computer Science Department 

P.O. Box 1910 

Providence, RI10912 

Email: <pbg@cs,brown,edu> 

Phone: 401/ 863-7623 
Fax: 401/ 863-7719 

Student Papers: 

There will be an award for the best student paper. 
Be sure to indicate with your submission if you 
are a full time student. A cash prize and free reg¬ 
istration will be awarded by the Conference Pro¬ 
gram Committee. 

Deadlines: 

Abstracts due: August 7,1993 

Notifications to authors: September 4,1993 

Final papers due: October 12,1993 

The Program Committee will select presentations 
from among those submitted. The committee 
consists of experts from many areas of the Sun/ 
Solaris arena, including: 

Pete Cottrell, U, of Maryland 

Casper Dik, U. of Amsterdam 

Dinah McNutt, Tivoli Systems 

Steven Miller, U. of Illinois 

Ruth Milner, Natl. Radio Astronomy Observatory 

Gene Rackow, Argonne National Lab 

Hal Stern, SMCC 

Leonardo Topa, MIT 
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It will be aided by: 

S. Lee Henry, SUG board liaison 
Johns Hopkins University 

Alex Newman, SUG liaison 
Sun User Group 

Michael Pearlman, SUG board liaison 
Rice University 

Possible themes and topics are listed below. 

These are only for reference, however, and all 
submitted papers will be considered for presenta¬ 
tion at the conference. 

Thematic Track 

Topics directly related to the theme of the pro¬ 
gram: Migrating from mainframes to Sun sys¬ 
tems, UNIX in the corporate environment. Suns 
and mission-critical work, Solaris 2 migration 
issues, ideas, and roadmap. 

Beginning UNiX/ Beginning System Administration 

Practical information for new users and system 
administrators. Presentations which will allow a 
new Sun user to be able to install workstations 
and keep them running. They could include file 
system layout, basic security, NIS, DNS, the boot 
process, script programming, user dot files, 
administration files, day-to-day operations, keep¬ 
ing a system log, using the resources available on 
the Internet, and so on. 

Minitutorials and Q&A 

These sessions should be designed to directly 
address Sun users' needs. They could include 
step-by-step guides to administration, network¬ 
ing, programming in various tools, and under¬ 
standing aspects of system operation such as 
performance and utilities. Q&A sessions are 
important and interesting to attendees because of 
their interactive, problem solving and question¬ 
resolving nature. Previous talks in this vein have 
included "securing your environment" and "sys¬ 
tem administration tips and tricks." 

System Administration, System Security 

Talks in this area should address the interests of 
those who have been SunOS users for a year or 
more. Some of the more in-depth topics: mixed 
environments, backups, PPP/SLIP, automounter, 
perl, tools for problem troubleshooting, and 
remote off-site administration. 


Programming and Development Environments 

These presentations concern Sun's programming 
languages and those offered by third-parties. 
With Sun's C compiler no longer bundled with 
the operating system there are opportunities for 
third party compilers. Also of interest are tools 
and techniques for program development. 

Technical Product Information 

This topic provides a chance for vendors to beat 
their own (technical) drums and describe the 
compelling technical advantages of their prod¬ 
ucts. Panels of competitive products will be 
assembled when it seems appropriate to do so. 
No sales-oriented or nontechnical talks will be 
accepted. 

Suns in the Office/Home 

How do you integrate Sun computers into the 
office? Topics can include PC-type products on 
the Sun, how well they emulate, communicate, or 
convert information and how well they are 
received, the interface to IBM PC and Apple net¬ 
works, mail and printer access, home hardware 
maintenance, links to the office (PPP/SLIP), 
product licensing, and Solaris on the Intel plat¬ 
form. 

Research, Real-time computing, Image Processing, 
Scientific 

Although there are other conferences that deal 
solely with the technical issues of research, this 
topic deals with how a Sun system facilitates 
research, and tools which can help the scientist. 
Topics include Suns and real-time computing, 
cross compiling (i.e., vxworks, os9, vrtx etc.), and 
data acquisition, among others. 
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A FREE Lunch! 



SUN 

USER GROUP 


Well...not really. But your Sun User Group membership you can save hundreds of 
dollars a year -- and that’s a whole lot of lunches. 

Here’s what you do get for your $40 yearly membership in SUG: 

$100 combined discount on registration at SUG’s two annual conferences - The place 
to go to see the state of the art in SUN/Sparc technology! 

Discounts worth hundreds of dollars with major technical publishers like 
Addison-Wesley, O’reilly & Associates, and Prentice Hall! 

Discounts on software and hardware from such leading vendors as Dux, Qualix, 
Software Moguls. Dataram worth hundreds more! 

The opportunity to purchase SUG’s award-winning software libraries. Hundreds of 
megabytes of useful software and archives, in one convenient compact disk. Available 
only to SUG members. 

•^’A subscription to Readme - SUG’s bimonthly newsletter, brimming with news, reviews, 
and Interviews that will keep you up to date with the rapidly changing Sun/Sparc 
environment! 

Access to SUG’s Members-only Electronic mailing list: the hot new forum for 
exchanging technical information and getting the inside scoop on What’s going on in the 
workstation world! 

If you use even one of these benefits, you will come out ahead - use a few, and you will 
consider your SUG membership to be the most valuable peripheral your SUN/Sparcstation 
is connected to! 

Sun User Group 1330 Beacon St., Suite 315, Brookline, MA 02146 

(617) 232-0514 voice 
(617) 232-1347/ox 
oJflce@sug.org 
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That’s right, you’ll receive 
your personal copy of 
the 1993 Open Systems 
Products Directory FREE 
with your paid membership 
in UniForum: The International 
Association of Open Systems 
Professionals. 


Acclaimed by UNlXWorld as “the 
most comprehensive guide to UNIX 
products,” the 1993 Directory con¬ 
tains more than 7500 products and 
services in one easy-to-use volume. 
Well designed indexes and tabs 
guide you right to the information 
you want. That’s why UNlXWorld 
calls the Directory “Old Reliable,” 
and why you’ll call it “indispens¬ 
able.” 

Boasting an extensive roster of 
2000-1- vendors, the Directory offers 
1500 pages of unmatched coverage 
of: 

■ Horizontal and Vertical Software 

■ Hardware Systems From PCs to 
Supercomputers 

V Peripherals From Modems to 
Printers 

■ Services From Employment 
Search to Training 

■ XPG and POSIX Conformance 
Information 


Priced to sell to non-members at 
$95.00, the 1993 Open Systems 
Product Directory is a real value. 
But why spend a penny extra 
when it’s yours free when you 
join UniForum? 

Becoming a member is a smart 
move. By joining you get the 
Directory plus all these member 
benefits: 

■ Subscription to UniForum 
Monthly — the colorful 
authoritative voice of the 
UNIX and Open Systems 
industry. 

■ Subscription to UniNews — 
the biweekly official 
newsletter of the Association 
containing insightful 
information you can rely on. 

■ UniForum Technical Publica¬ 
tions — precise and credible, 
written by today’s leading 
experts on systems and 
standards. 


■ Member discounts to all 
UniForum conferences and 
trade shows, 

■ Discounts on publications 
and services from publishers 
and vendors ^— available 
exclusively to UniForum 
members. 

Your membership entitles you 
to all of this, and the 1993 Open 
Systems Products Directory is 
yours FREE, when you join. 
Membership is only $100.00 per 
year and ordering is easy, too. 

In the U.S. call toll free 
1-800-255-5620; calling from out¬ 
side the U.S. dial 408-986-8840. 
Have your major credit card 
ready and we’ll start your mem¬ 
bership at once. 

You won’t find a better offer 
anytime soon. So call now and 
become part of the largest group 
of open systems professionals in 
the world. Join UniForum, today! 


® UniForum 

The International Association of Open Systems Prolessionats 


2901 Tasman Drive, Suite 201, Santa Clara, CA 95054 (800)255-5620 (408)986-8840 FAX: (408) 986-1645 
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Publications Order Form 


Conference & Workshop Proceedings 


Qty Proceedings 

Member 

Price 

Non-Member* 

Price 

Subtotal 

Overseas 

Postage 

Total 

WINTER/SLJMMER CONFERENCES 







San Diego 

Winter '93 

33 

40 

$ 

$25 

$ 

San Antonio 

Summer '92 

23 

30 

$ 

14 

$ 

San Francisco 

Winter '92 

‘ 30 

39 

S 

22 

$ 

Nashville 

Summer '91 

32.. 

38 

$ 

22 

$ 

Dallas 

Winter '91 

28 S: ’ 

34 

$ 

18 

$ 

Anaheim 

Summer '90 

; ^ 22: 

22 

$ 

15 

$ 

Washington, DC 

Winter '90 

25 

25 

$ 

15 

$ 

Baltimore 

Summer '89 

20 

20 

$ 

15 

$ 

San Diego 

Winter '89 

30 

30 

$ 

20 

$ 

San Francisco 

Summer '88 

29 

29 

$ 

20 

S 

Dallas 

Winter'88 

26 

26 

$ 

15 

s 

Phoenix 

Summer'87 

35 

35 

$ 

20 

s 

Washington, DC 

Winter '87 

10 

10 

s 

15 

$ 

Atlanta 

Summer '86 

37 

37 

s 

20 

$ 

Denver 

Winter'86 

25 

25 

$ 

15 

s 

Portland 

Summer *85 

45 

45 

$ 

25 

s 

Dallas 

Winter'85 

15 

IS 

$ 

10 

$ 

Salt Lake City 

Summer '84 

29 

29 

s 

20 

$ 

Washington, DC 

Winter '84 

25 

25 

s 

15 

$ 

Toronto 

Summer '83 

32 

32 

s 

20 

$ 

San EHeeo 

Winter '83 

28 

28 

s 

15 

s 

LARGE INSTALLATION SYSTEMS ADMINISTRATION 






USA VI 

Oct. '92 

23 

30 

$ 

12 

s 

LISAV 

Sept. '91 

20 

23 

s 

11 

$ 

LISA IV 

Oct. '90 

15 

18 

$ 

8 

s 

USA III 

Sept. '89 

13 

13 

$ 

9 

$ 

USA II 

Nov. '88 

; 8 

8 

s 

5 

$_ 

LISA I 

April '87 

I 4 

4 

$ 

5 

$ 

C++ 






C++ Conference 

Aug. '92 

30 

39 

$ 

Z) 

$ 

C++ Conference 

April '91 

22 

26 

$ 

11 

$_ 

C++ Conference 

April '90 

28 

28 

$ 

18 

$ 

C++ Conference 

Oct. '88 

^ 30 

30 

$ 

20 

$ 

C++ Workshop 

Nov. '87 

30 

30 

$ 

20 

$ 

SECURITY 







UNIX Security III 

Sept. '92 

30 

39 

$ 

11 

$ 

UNIX Security II 

Aug. 90 

13 

16 

$ 

8 

$ 

UNIX Security 

Aug. '88 

7 

7 

$ 

5 

$ 

MACH 






Mach Symposium III 

April '93 

30 

39 

$ 

18 

$ 

Mach Symposium 

Nov. 91 

24 

28 

$ 

14 

$ 

__ Mach Workshop 

Oct. '90 

17 

20 1 

$ 

9 

$ 


Continued - see reverse 


May/June 1993 ;login: 61 






Qhf Proceedings 

Member 

Price 

Won-Member* 

Price 

Subtotal 

Overseas 

Postage 

Total 

DISTRIBUTED & MULTIPRCKIESSOR SYSTEMS (SEDMS) 






_ SEDMS m 

Mar. '92 

30 

36 

$ 

20 

$ 

SEDMS II 

Mar. '91 

30 

36 

$ 

20 

$ 

SEDMS 

Oct.'89 

; 30 

30 


20 

$ 

GRAPHICS 







Graphics Workshop V 

Nov.'89 

18 

18 

$ 

10 

$ 

Graphics IV 

Oct.'87 

10 

10 

$ 

10 

$ 

Graphics ID 

Nov.'86 

TO 

10 

$ 

5 

$ 

Graphics II 

Dec. '85 

7 

7 


5 

$_ 

OTHER WORKSHOPS 







File Systems 

May'92 


20 

s__ 

9 

$ 

_ Micro-Kernel & Other Kernel Arch. 

April '92 

30 

39 

$ 

20 

$ 

_ UNIX Transaction Processing 

May'89 

12 

12 

$ 

8 

$ 

_ Software Management 

Apr. '89 

20 

20 

$ 

15 

$ 

_ UNIX & Supercomputers 

S^. '88 

20 

20 

$ 

10 

$ 


Discounts are available for bulk orders. Please inquire. Total price of Proceedings _ 

Calif, residents add sales tax _ 

Total overseas postage _ 

Total enclosed 

♦♦If you are paying member price, please include member’s name and/or 
membership numbe r _ 


PAYMENT OPTIONS* 

_ Check enclosed- payable to USENDC Association 

_ Chaise my: _ VISA _ MC | Account # _ Exp.Date 

_ Purchase order enclosed Signature --. 

♦ Outside the USA? Please make your payment in US currency by one of the following: 

- Check - issued by a local branch of a US Bank 

- Charge (VISA, MasterCard, or foreign equivalent) 

- International postal money order 

Shipping Information Ship to: 

Please allow 2-3 weeks for delivery. Overseas orders 
are shipped via air printed matter. 

Please mail or fax this order form with payment to: 

USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
FAX 510/548-5738 

• If you are not a member and wish to receive our membership information packet, please check this box. d 
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Membership Application 


MEMBERSHIP INFORMATION 

Any individual or institution may become a member of the USENIX Association by filling 
out an application form and paying the appropriate annual fee. 

There are five classes of membership: 

Student: $20 

Open to any full-time student at an accredited educational 
institution. A copy of the current student l.D. card must be 
provided. 

Individual: $65 

Open to any individual or institution. Individual Members 
may vote. 

Corporate: $325 

Corporate Membership is open to any individual or 
institution. 

SAGE, the System Administrators' Guild 

The System Administrators' Guild (SAGE) is a Special Technical Group within the USENIX Association, devoted to the furtherance of 
the profession of systems administration. SAGE brings together system administrators for professional development, for the sharing 
of problems and solutions, and to provide a common voice to users, management, and vendors on topics of system administration. 

A number of working groups within SAGE are focusing on special topics such as conferences, local organizations, professional and tech¬ 
nical standards, policies, system and network security, publications, and education. USENIX and SAGE will work jointly to publish 
technical information and sponsor conferences, tutorials, and local groups in the systems administration field. 

To become a SAGE member you must be a member of USENIX as well 

MEMBERSHIP APPLICATION 


Educational: $160 

Educational Membership is open to accredited educational 
insti^tions. 

Supporting: $1000 

Open to any individual or institution that wants to support 
the Association to a greater degree than through the Corporate 
Membership fee. 

Corporate, Educational and Supporting members have one designated 
representative who receives all services available to Individual 
Members, plus copies of the proceedings from all conferences and 
symposia that are held during the term of membership. 


New Q Renewal | | 


Name 

Address 


City_Sta te Zip Country 

Phone email address: 


I I $20 Student (full-time) 

{with copy of l.D, card) 
LJ $65 Individual 


I I $160 Educational Institution CH $25 - SAGE (Additional) 
I I $325 Corporate 
I I $1000 Supporting 


PAYMENT OPTIONS 


I I My total amount for membership is $_. 

I I Check enclosed payable to USENIX Association. 

I I Please charge my: Q Visa Q MasterCard 


[m Purchase order enclosed (Educational and Corporate 
IMj members only). 


Account # 


Exp. Date 


Signature 


Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 5/93 


$24 of your annual membership dues is for a one-year subscription to the newsletter, ;login.\ and $30 of your dues is for a one-year subscription to the 
journal, Computing Systems. 


USENIX Mailing List 

I I I do not want my address made available to other members. 

I—I I do not want my address made available for commercial mailings. 
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FL • Melbourne 


Local User Groups 


The Association will support local user groups by 
doing a mailing to assist in the formation of a new 
group and publishing information on local 
groups in ;login:. At least one member of the 
group must be a current member of the Associa¬ 
tion. Send additions and corrections to: 
login@usenix.org, 

CA-Fresno: 

The Central California UNIX Users Group con¬ 
sists of a uucp-based electronic mailing list to 
which members may post questions or informa¬ 
tion. For connection information: 

Educational and governmental institutions: 
Brent Auernheimer (209) 278-2573, 
<hrent@CSUFresno,edu or csufres!brent> 

Commercial institutions or individuals: 

Gordon Crumal (209) 251-2648 
<csufreslgordon> 

CA-Orange County: 

Meets the 2nd Monday of each month 

UNIX Users Association of Southern California 
Paul Muldoon (714) 556-1220 ext. 137 
New Horizons Computer Learning Center 
1231 E. Dyer Rd., Suite 140 
Santa Ana, CA 92705 

CO-Boulder: 

Meets monthly at different sites. For meeting 
schedule, send email io< fruug-mfo@fruug.org>. 

Front Range UNIX Users Group 
Software Design & Analysis, Inc. 

1113 Spruce St., Ste. 500 
Boulder, CO 80302 
Steve Gaede (303) 444-9100 
<gaede@fruug.org> 

D.C.- IVasWngfon, D.C.; 

Meets 1st Tuesday of each month. 

Washington Area UNIX Users Group 

9811 Mallard Drive 

Laurel, MD 20708 

Alan Fedder (301) 953-3626 

FL - Coral Springs 

S. Shaw McQuinn (305) 344-8686 
8557 W. Sample Road 
Coral Springs, FL 33065 


Meets the 3rd Monday of every month. 

Space Coast UNIX User's Group 
Steve Lindsey (407) 242-4766 
<Undsey@imetjbm,com> 

FL - Orlando: 

Meets the 3rd Thursday of each month. 

Central Florida UNIX Users Group 
Mikel Manitius (407) 444-8448 
<mike@aaa.com> 

FL - Western: 

Meets 1st Thursday of each month. 

Florida West Coast UNIX Users Group 
Richard Martino (813) 536-1776 
Tony Becker (813) 799-1836 
<mcrsi/s.^fony> 

Ed Gallizzi, Ph.D. (813) 864-8272 
<e.gallizzi@compmail.com> 

Jay Ts (813) 979-9169 
<uunet!pdn!tscs!metran!jan> 

Dave Lewis (407)242-4372 
<dhl@ccd.harris.com> 

GA -Atlanta: 

Meets on the 1st Monday of each month in 
White Hall, Emory University. 

Atlanta UNIX Users Group 
RO. Box 12241 
Atlanta, GA 30355-2241 
Mark Landry (404) 365-8108 

KS or MO - Kansas: 

Meets on 2nd Monday of each month. 

Kansas City UNIX Users Group (KUUG) 

813B Street 

Blue Springs, MO 64015 
(816) 235-5212 
<mlg@cstp.umkc.edu> 

Ml - Detroit/Ann Arbor 

Meets on the 2nd Thursday of each month in Ann 
Arbor. 

Southeastern Michigan Sun Local Users Group 
and Nameless UNIX Users Group 
Steve Simmons office: (313)769-4086 
home: (313) 426-8981 
<scs@lokkur.dexter.mi.us> 
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MN - MinneapoHs/St Paul: 

Meets the 1st Wednesday of each month, 

UNIX Users of Minnesota 
17130 Jordan Court 
Lakeville, MN 55044 
Robert A. Monio (612) 220-2427 
<pnessutt@dmshq.mn.org> 

MO-St Louis: 

St. Louis UNIX Users Group 
RO. Box 2182 
St. Louis, MO 63158 
Terry Linhardt (314) 772-4762 

< u unet !jgaltstl!teriy> 

NE- Omaha: 

Meets monthly. 

/usr/group/nebraska 

P.O. Box 31012 

Omaha, NE 68132 

Phillip Allendorfer (402) 423-1400 

New England - Northern: 

Meets monthly at different sites. 

Peter Schmitt 603) 646-2085 
Kiewit Computation Center 
Dartmouth College 
Hanover, NH 03^5 
<peter.schmitt@dartmouth.edu> 

NJ - Princeton: 

Meets monthly. 

Princeton UNIX Users Group 

Mercer County Community College 

1200 Old Trenton Road 

Trenton, NJ 08690 

Peter J. Holsberg (609) 586-4800 

<mccc!pjh> 

NM ~ Albuquerque: 

ASIGUNIX meets every 3rd Wednesday 
of each month. Phil Hortz 505/275-0466. 

NY-New York City: 

Meets every other month in Manhattan. 

Uni group of New York City 
G.PO. Box 1931 
New York, NY 10116 

< w n ig ro } 11 rphy. com > 

Bob mung 

(212) 4^90-8470 


OK-Tulsa: 

Meets 2nd Wednesday of each month. 

Tulsa UNIX Users Group, $USR 
Stan Mason (918) 560-5329 
<tulsix!smason@drd.com> 

Mark Lawrence (918) 743-3013 
<mark@drd.com> 


TX-Austin: 

Meets 3rd Thursday of each month. 

Caoital Area Central Texas UNIX Society 
P.O. Box 9786 
Austin, TX 78766-9786 
<officers@cactus.org> 

Tom Painter (512) 835-5457 
<president@cactus.org> 

TX - Dallas/Fort Worth: 

Meets the 1st Thursday of each month. 

Dallas/Fort Worth UNIX Users Group 

PO. Box 867405 

Plano, TX 75086 

Evan Brown (214) 519-3577 

<evhrown@dsccc.com> 

TX-Houston: 

Meets 3rd Tuesday of each month. 

Houston UNIX Users Group 

(Hounix) answering machine (713) 684-6590 

Bob Marcum, President (713) 270-8124 

Chuck Bentley, Vice-president 

(713) 789-8928 

<chuckb@hounix.uucp> 

WA -Seattle: 

Meets monthly. 

Seattle UNIX Group Membership Info. 

Bill Campbell (206) 947-5591 
6641 East Mercer 
Mercer Island, WA 98040-0820 
<bill@celestial.com> 

CANADA - Toronto: 

143 Baronwood Court 
Brampton, Ont. Canada L6V 3H8 
Evan Leibovitch (416) 452-0504 
<evan@telly.on.ca> 


CANADA - Ottawa: 

The Ottawa Carleton UNIX Users Group 
D.J. Blackwood (613)957-9305 
<dave@revcan.rct.ca> 
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BAY LISA 


LISA Groups 
Back Bay LISA 

Forum covering all aspects of system and net¬ 
work administration, for large and small installa¬ 
tions. Meets Monthly, various locations in Boston. 

JR. Oldroyd 
The Instruction Set 
601 Trapelo Road 
Waltham MA 01254 
617/ 890-4930 
<jr@inset.com> 

Mailing list:< bblisa@in$et.com> 

List Requests: <bblisa-request@inset.com> 


The Bay-LISA group meets monthly in Santa 
Clara, CA to discuss topics of interest for admin¬ 
istration of sites with more than 100 users and/or 
computers. 

Send email to <baylisa-info@sysadmin.com> 
or contact: 

Bjorn Satdeva 
408/ 241-3111 
<bjorn@sysadmin.com> 


Prime Time Freeware 


Volume 2, Number 1 


Volume 2, Number 2 


PTF 2-1 contains 1200 MB of compressed 
archives, unpacking to more than 3000 MB of 
source code and documentation, current as of 
January 15,1993. Here are some of the larger 
items, prefaced by their compressed sizes: 

KB (C) Package Name 

299508 UK TeX (LaTeX, etc.) Archive 

82198 SRCModula-3 

81650 NetLib Archive (math and sim.) 

78792 ICOT (5th Gen. AI Code) 

36548 Interviews (UI dev. system) 

36540 Scheme Language 

34040 Ptolemy (HW CAD and sim. system) 

26964 StatLib Archive (statistics.) 

26206 Cygnus Progressive Release 

19773 POSTGRES RDBMS 

18046 CMU Common Lisp 

15752 AnalytiCalc 

15457 Icon Language 

12748 Barkley Tcl/Tk Archive 

12478 Self Language 

12070 G++ (etc.) for DOS 

11710 Lucid Emacs 

11672 GoPATH (UI Dev. System) 

11137 GCC (C++ compiler, etc.) 

11134 Std. ML of New Jersey 


PTF 2-2 will be available in July, 1993. It will con¬ 
tain updated copies of small and/or updated 
packages from PTF 2-1, an updated selection of 
materials from PTF 1-2, and a variety of totally 
new material. Contact PTF <ptf®cfcLcom> for 
details, after ]uly 1. 

Ordering and Prices 

PTF issues cost $60 (a special discounted price of 
$50 for SUG and USENIX members), plus 7% tax if 
in California and shipping/handling charges, as 
follows: 


S/H Item 1 Items 2-N 

USA $5 $1 each 

Foreign $10 $4 each 

PTF takes Mastercard and Visa, postal money 
orders in US funds, and checks in US funds that 
are payable through a us bank. Either issue (two 
ISO-9660 CD-ROMs and a 50+ page booklet) can 
be ordered from: 


Prime Time Freeware 
370 Altair Way, #150 
Sunnyvale, CA 94086 
Tel: +1 408/433-9662 
Fax: +1 408/432-6149 
Email: <ptf@cfcl.com> 
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Calendar of Events 


1993 

Jun 5-11 DECUS, Atlanta, GA 
8-10 CERT Security Seminars 

21- 25 * USENIX, Cincinnati, OH 

Jul 7- 9 SAGE-AU, Melbourne, AustraEa 
12-16 IEEE 1003, Denver, CO 
27-29 Sun User Group-East, Boston, MA 
Aug 1 ACM Siggraph, Anaheim, CA 
2 - 3 * Mobile & Location-Independent 
Computing, Cambridge, MA 
10-13 FIRST Computer Security Incident 
Handling, St. Louis, MO 

17- 20 INET '93, San Francisco, CA 
23-27 INTEROP, San Francisco, CA 

Sept 20-22 * Microkernels II, San Deigo, CA 
23-24 ♦ SEDMSIV, San Diego, CA 

22- 24 EurOpen/GUUG, Wiesbaden, FRG 
26 - ACM OOPSLA, Washington, DC 

Oct 1 

Sept 27-30 AUUG, Sydney, Austraha 

Oct 4-6 * UNIX Security Symposium IV, 

Santa Clara, CA 
14-15 WWOS -TV, Napa, CA 

18- 22 IEEE 1003, Bethesda, MD 

25-29 INTEROP '93 Europe, Paris, France 

Novi- 5 * LISAVII,Monterey,CA 

3-5 * NOSSDAV Workshop, Lancaster, UK 
29 - FedUNIX, Washington, DC 
Dec 3 

.4-10 DECUS, San Francisco, CA 
7-9 Sun User Group, San Jose, CA 
8-10 JUS UNIX Fair, Japan 

1994 

Jan 10-14 IEEE 1003, Irvine, CA 

17-21 USENIX, San Francisco, CA 

Mar 23-25 UniForum, San Francisco, CA 
Apr 11-14 * C++, Cambridge, MA 

25-28 * UNIX Applications Development 
Toronto, Canada 

Apr TBA SANS III, Washington, D.C. area 
May 2- 6 Networld+INTEROP 94, Las Vegas, NV 


May 7-13 DECUS, New Orleans, LA 

Jun 6-10 * USENIX, Boston, MA 

Sept 12-16 Networld+INTEROP 94, Atlanta, GA 

Oct 23-27 ACM OOPSLA, Portland, OR 

Nov 12-18 DECUS, Anaheim, CA 

1995 ■ 

Jan 16-20 USENIX, New Orleans, LA 
Feb 21-23 UniForum, Dallas, TX 
May 13-19 DECUS, New Orleans, LA 

Jun 19-23 * USENIX, San Francisco, CA 
Nov 2- 8 DECUS, San Francisco, CA 

1996 

Jan 22-26 * USENIX, San Diego, CA 
Mar 12-14 UniForum, San Francisco, CA 
May 18-24 DECUS, Orlando, FL 
Nov 16-22 DECUS, Anaheim, CA 

This is a combined calendar of planned confeiences, sym¬ 
posia, and standards meetings related to the UNIX operat¬ 
ing s3/stem. If you have a UNIX-related event that you 
wish to publicize, please contact <log^in@usefiix.org>. 
Please provide your information in the same format as 
above. 

* = events sponsored by the USENIX Association. 


ACM: Association for Computing Machinery 
AUUG: Australian UNIX Users Group 
CERT: Computer Emergency Response Team 
DECUS: Distal Equipment Computer Users Society 

EurOpen: European Forum for Open Systems 
FedUfsIIX: Council of Advanced Computing Systems 
Technologists in Government 
FIRST: Forum of Incidence Response & Security Team 
IEEE: Institute of Electrical and Electronics Engineers 

IETF: Internet Engineering Task Force 
INET: Internet Society 

Interex: Inti. Association of Hewlett-Packard Comp.Users 
JUS; Japan UNIX Society 

LISA: USENIX Systems Administration Conference 
NOSSDAV: Network and Operating System Support for 
Digital Audio and Video 

OOPSLA: Object - oriented Programming Systems, 
Languages, and Applications 
SAGE: System Administrators' Guild 

SANS: System Adminstration, Networking & Security 
SEDMS: ^mposium on Experiences withDistributea 
and Multiprocessor Systems 
UKUUG: United Kingdom UNIX Systems Users Group 
UniForum: International Association of UNIX and 
C^en Systems Professionals 
WWOS: Workshop on Workstation Operating Systems 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


Second Class Postage 
PAID 

At Berkeley, California 
and Additional Offices 


POSTMASTER: Send address changes to ;login:, USENIX Association, 2560 Ninth Street, Suite 215, Berkeley, CA 94710 
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> UPCOIVIINO SYlviPOSiA AND CONFERENCES^ ^ 


AUGUST 2-3.1993 

SEPTEMBER 20-22.1993 

SEPTEMBER 23-24.1993 

SYMPOSIUM ON MOBILE & 
LOCATION-INDEPENDENT 
COMPUTING 

Program Chair: Dan Geer, 

Geer Zolot Associates 
Vice-Program Chair: Clement Cole, 
Locus Computing Corporation 

Marriott Hotel, 

Cambridge, Massachuetts 

2ND SYMPOSIUM ON 
MICROKERNELS a 

OTHER KERNEL ARCHITECTURES 

Program Chair: Lori S. Grob, 

Chorus systemes 

Hilton Beach & Tennis Resort, 

San Di^g^alifornia 

EXPERIENCES WITH DISTRIBUTED 
a MULTIPROCESSOR SYSTEMS 
(SEDMS IV) 

General Chair: Peter Reiher, UCLA 
Program Chair: David Cohn, 
University of Notre Dame 

Hilton Beach & Tennis Resort, 

San Diego, California 

In cooperation with: ACM SIGARCH, SIGCOMM, SIGOPS and SIGSOFT 
and lEEE-CS Technical Committees on Distributed Processing, 
Operating Software Engineering, and Design Automation 


OCTOBER 4-7.1993 

NOVEMBER 1-S, 1993 

JANUARY 17-21,1994 

4TH 

UNIX SECURITY SYMPOSIUM 

Program Chair: Bill Cheswick, 

AT&T Bell Laboratories 

Santa Clara Marriott Hotel, 

Santa Clara, California 

Co-sponsored with The Computer Emergency Response Team (CERT) 

In cooperation with The ACM SIGSAC 

W‘ 

7TH SYSTEMS ADMINISTRATION 
CONFERENCE 
(LISA VII) 

Co-sponsored with SAGE, 
the Systems Administrators' Guild 

Program Chair: Bjorn Satdeva, 
/sys/admin, inc. 

Marriott Hotel, 

Monterey, California 

WINTER 1994 
TECHNICAL CONFERENCE 

Program Chair, Jeffrey Mogul, 
Digital Equipment Corporation 

San Francisco Hilton 

San Francisco, California 

||P|i 

1 _ 


TO RECEIVE FULL IHFORMRTIOH 

Please contact: USENIX Conference Office, 22672 Lambert St., Suite 613, Lake Forest, CA USA 92630 
•••1 (714) 588-8943; FAX: +1 (714) 588-9706; e-maii: upcoming@usenix.org 





